Высокая загрузка процессора

Высокая загрузка процессора, UniFi Protect

82280zx

Guest

03.06.2022 15:18:00

Обновляюсь до 2.0.1... Наш protect работает очень медленно с момента обновления, а сегодня утром он завис при перезагрузке... пришлось перезагружать его через консоль. И это нормально для 2.0.1? У меня тоже долго обновляется до него, а вот такая загрузка...

82280zx

Guest

12.07.2022 17:44:00

@UI-Glenn Версия Protect 2.1.1-beta.11, кажется, решила проблемы с перезагрузками, которые были у нашего UNVR. Я обновился до этой версии час назад и перенес камеры обратно на UNVR с UDM Pro. Если возникнут какие-нибудь проблемы, сообщу об этом.

Canntech

Guest

11.07.2022 08:13:00

Подтверждено ли, что эта проблема возникает только на UNVR? У меня тоже похожая проблема с UDM Pro, работающим под Protect 2.0.1. Попробовал метод Talk, который упоминал @RoChess, и, кажется, это немного помогает, но загрузка ЦП всё равно довольно высокая (80 - 90%). Это при примерно 9 камерах.

RoChess

Guest

09.07.2022 03:38:00

Вот что получается, когда врываешься в обсуждение поспешно и не читаешь всю тему. Я не видел, чтобы другие сообщали о 100% загрузки CPU на выделенных юнитах, разве что при огромной нагрузке с камер. Если с какими-то HDD есть проблемы, это может косвенно привести к чрезмерной загрузке CPU, потому что повторные попытки SATA могут мешать. Получали ли данные SMART по SSH, чтобы убедиться, что со здоровьем дисков всё в порядке? В противном случае, можно быстро проверить, используя один, заведомо исправный диск (хотя не уверен, как это повлияет на существующий том на swap). Жду возврата партий UNVR-Pro, поэтому пока полагаюсь на UDM-Pro.

82280zx Guest	#5 08.07.2022 22:46:00 @RoChess Это 100% загрузка ЦП на UNVR, UNVR может запускать только Protect и UID.

82280zx Guest	#6 08.07.2022 22:08:00 Наша UNVR сейчас нерабочая, камеры вернул на UDM Pro's protect, пока что. (У меня там старая прошивка protect (1.21.6), но она отлично работает), поэтому хоть что-то работает.

RoChess

Guest

08.07.2022 22:22:00

Приложение Talk было известно тем, что вызывало 100% загрузку процессора, что легко проверить через 'top' в SSH-сессии, когда приложение Free* потребляет много ресурсов. Обновление приложения Talk до текущей версии это прекратит, и это нужно даже если Talk не используется. Новая UniFi OS позволяет снова удалять приложение, но это пока не попало в стабильный/официальный канал.

helpdesk@amaro.com Guest	#8 08.07.2022 21:45:00 У меня та же проблема с UDM Dream Machine.

82280zx Guest	#9 08.07.2022 17:53:00 @UI-Glenn, я не могу обновить свой UNVR из веб-интерфейса. Обновление Protect 2.0.1 зависло на "Starting...". И Unifi OS тоже не обновляется, выдаёт ошибку. Есть ли способ сделать это через SSH? Редактирую: Перезагрузил его из веб-интерфейса, обновление Unifi OS заняло некоторое время, теперь обновляю Protect. Будем тестировать отсюда, если возникнут проблемы, отпишусь. Обновление: Скачал и обновил новую версию Protect, но она не запускается... Перезагружаю консоль ещё раз, посмотрим, поможет ли это. Обновление 2: Protect 2.1.1-beta.9 загрузился, но я не могу подключить ни одну из своих камер... Сейчас тестирую с одной, пока не особо получается. Обновление 3: Камеры нужно отключить от управления, прежде чем их можно будет переподключить, но процесс переподключения камер занимает очень много времени... Но кажется, что идёт какой-то прогресс? Буду держать вас в курсе, если будут новые проблемы. Обновление 4: Отключил Low Latency Video в настройках... Это привело к краху Protect, и он не запустился, поэтому перезагрузил UNVR через веб-интерфейс. Это заняло 5+ минут, но он снова заработал, при этом Low Latency Video снова включён. Консоль: root@TSRP001RP:~# systemctl start unifi-protect A dependency job for unifi-protect.service failed. See 'journalctl -xe' for details. root@TSRP001RP:~# journalctl -xe ---- A start job for unit postgresql-cluster@9.6-protect-migrate.service has finished successfully. ---- The job identifier is 1048. Jul 08 15:35:31 TSRP001RP systemd[1]: postgresql-cluster@9.6-protect-migrate.service: Consumed 98ms CPU time. ---- The unit postgresql-cluster@9.6-protect-migrate.service completed and consumed the indicated resources. Jul 08 15:35:31 TSRP001RP systemd[1]: Starting PostgreSQL initial setup service... ---- A start job for unit postgresql-cluster@9.6-protect.service has begun execution. ---- The job identifier is 1047. Jul 08 15:35:31 TSRP001RP systemd[1]: Reloading. Jul 08 15:35:32 TSRP001RP systemd[1]: /lib/systemd/system/postgresql@.service:12: PIDFile= references path below Jul 08 15:35:32 TSRP001RP systemd[1]: /lib/systemd/system/postgresql@.service:12: PIDFile= references path below Jul 08 15:35:32 TSRP001RP systemd[1]: /lib/systemd/system/rpc-statd.service:13: PIDFile= references path below Jul 08 15:35:32 TSRP001RP -bash[13905]: HISTORY: PID=13905 UID=0 journalctl -xe ~~~Это происходит после отключения Low Latency Video...

Читают тему (гостей: 1)