Помогите! Protect не запускается из-за того, что в Postgres закончилась память.

Помогите! Protect не запускается из-за того, что в Postgres закончилась память., UniFi Protect

fes

Guest

22.05.2019 05:01:00

Unifi Protect у меня перестал работать и не запускается. В логах полно таких сообщений:
2019-05-20T14:42:50.452Z - error: Error: connect ENOENT /var/run/postgresql/.s.PGSQL.5432
at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1191:14)

Я решил посмотреть логи Postgres и увидел следующее:
2019-05-21 21:46:29.780 PDT [17291] LOG: database system was shut down at 2019-05-15 13:11:27 PDT
2019-05-21 21:46:29.799 PDT [17293] [unknown]@[unknown] LOG: incomplete startup packet
2019-05-21 21:46:29.822 PDT [17291] FATAL: could not write to file "pg_xlog/xlogtemp.17291": No space left on device
2019-05-21 21:46:29.825 PDT [17287] LOG: startup process (PID 17291) exited with exit code 1
2019-05-21 21:46:29.825 PDT [17287] LOG: aborting startup due to startup process failure
2019-05-21 21:46:29.829 PDT [17287] LOG: database system is shut down

pg_xlog находится в /srv/log, значит:
root@UniFi-CloudKey-Gen2-Plus:/srv/db# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 32G 32G 15M 100% /srv/db

То есть, /srv/db заполнен полностью, а конкретно:
root@UniFi-CloudKey-Gen2-Plus:/srv/db# du -h .
32G ./postgresql/9.6/main/base/16385

Как это исправить? Похоже, что место закончилось несколько дней назад.

brianstar

Guest

20.08.2021 01:58:00

Есть какие-то решения? У меня происходит то же самое с 39 камерами, настроенными на постоянную запись, так что не уверен, что проблема в детекторе движения. Честно говоря, я не знаю, как выполнить команды, чтобы узнать процент для отчёта. Буду благодарен за помощь. Я могу подключиться по ssh и запустить top. Postgres загружен на 100%.

hoep Guest	#3 18.01.2021 12:09:00 P.S. пытался освободить немного места в каталоге /db.

hoep

Guest

18.01.2021 12:06:00

Та же история: пожалуйста, поделитесь скриптом и инструкциями.

root@Cloudkey:~# df -h
Файловая система Размер Использовано Доступно Использовано% Точка монтирования
udev 1,5G 0 1,5G 0% /dev
tmpfs 299M 4,9M 294M 2% /run
/dev/mmcblk0p46 5,9G 655M 5,2G 12% /mnt/.rwfs
/dev/disk/by-partlabel/rootfs 363M 363M 0 100% /mnt/.rofs
overlayfs-root 5,9G 655M 5,2G 12% /
tmpfs 1,5G 0 1,5G 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 1,5G 0 1,5G 0% /sys/fs/cgroup
tmpfs 746M 132K 746M 1% /tmp
/dev/mmcblk0p45 976M 183M 768M 20% /persist
/dev/mmcblk0p47 19G 45M 19G 1% /srv-internal
/dev/sda4 4,5T 4,5T 32G 100% /srv
/dev/sda2 16G 293M 16G 2% /srv/var
/dev/sda3 32G 32G 65M 100% /srv/db
/dev/mmcblk1p1 59G 806M 58G 2% /data

root@Cloudkey:~#

olemskoi Guest	#5 31.07.2020 19:39:00 Та же проблема с CloudKey-Gen2-Plus. @UI @UI-Cody, пожалуйста, пришлите мне скрипт. /dev/sda3 32G 32G 0 100% /srv/db

csutcliff

Guest

22.07.2020 16:16:00

@UI @UI-Cody такая же проблема, там будет слишком много событий движения, надо признать, я выбрал новый алгоритм и забыл потом вернуться и настроить его. Можете дать скрипт, чтобы это исправить? /dev/sda3 32G 32G 108K 100% /srv/db

welltech Guest	#7 20.07.2020 14:04:00 @UI-Cody У меня такая же проблема с директорией /srv/db на 100%. Пожалуйста, пришли мне скрипт.

welltech Guest	#8 17.07.2020 09:30:00 @horizonadmin @bdraco @acsunifi @bgaston @telecoIT @mattbernard @adamrothman @Safemode @ZakiniNetAlerts Не могли бы вы как можно скорее поделиться скриптом со мной?

Wolfy3605

Guest

12.05.2020 21:32:00

@UI-Cody У меня такая же история:
2020-05-13 04:03:40.809 CST [1150] postgres@postgres FATAL: система базы данных запускается
2020-05-13 04:03:41.221 CST [1086] LOG: база данных была некорректно завершена; выполняется автоматическое восстановление
2020-05-13 04:03:41.327 CST [1086] LOG: повтор начинается с 2E/D9FFFD68
2020-05-13 04:03:41.330 CST [1165] postgres@postgres FATAL: система базы данных запускается
2020-05-13 04:03:41.491 CST [1086] FATAL: не удалось получить статус транзакции 0
2020-05-13 04:03:41.491 CST [1086] DETAIL: не удалось записать в файл "pg_clog/0076" на смещении 180224: на устройстве нет свободного места.
2020-05-13 04:03:41.491 CST [1086] CONTEXT: xlog повтор на 2E/DA7D0030 для CLOG/ZEROPAGE: 3798
2020-05-13 04:03:41.495 CST [999] LOG: процесс запуска (PID 1086) завершился с кодом 1
2020-05-13 04:03:41.495 CST [999] LOG: прерывание запуска из-за сбоя процесса запуска
2020-05-13 04:03:41.499 CST [999] LOG: система базы данных остановлена

Файловая система:
Filesystem Size Used Avail Use% Mounted on
udev 1.5G 0 1.5G 0% /dev
tmpfs 299M 15M 284M 5% /run
/dev/mmcblk0p46 5.9G 27M 5.8G 1% /mnt/.rwfs
/dev/disk/by-partlabel/rootfs 362M 362M 0 100% /mnt/.rofs
overlayfs-root 5.9G 27M 5.8G 1% /
tmpfs 1.5G 0 1.5G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup
tmpfs 746M 136K 746M 1% /tmp
/dev/mmcblk0p45 976M 2.6M 948M 1% /persist
/dev/mmcblk0p47 19G 45M 19G 1% /srv-internal
/dev/sda4 4.5T 4.5T 32G 100% /srv
/dev/sda3 32G 32G 4.0K 100% /srv/db
/dev/sda2 16G 214M 16G 2% /srv/var

Пришли, пожалуйста, скрипт, как только сможешь.

RikkieV

Guest

#10

11.05.2020 12:59:00

@UI-Cody Похоже, у меня такая же проблема с CK2+, postgresql не запускается. Система работала примерно две недели, когда это случилось. Перезагрузка не помогает.

2020-05-11 05:22:03.198 PDT [13158] LOG: database system was interrupted; last known up at 2020-05-06 09:56:47 PDT
2020-05-11 05:22:03.387 PDT [13160] root@root FATAL: the database system is starting up
2020-05-11 05:22:03.519 PDT [13162] [unknown]@[unknown] LOG: incomplete startup packet
2020-05-11 05:22:03.644 PDT [13158] LOG: invalid primary checkpoint record
2020-05-11 05:22:03.644 PDT [13158] LOG: invalid secondary checkpoint record
2020-05-11 05:22:03.644 PDT [13158] PANIC: could not locate a valid checkpoint record
2020-05-11 05:22:03.646 PDT [13157] LOG: startup process (PID 13158) was terminated by signal 6: Aborted
2020-05-11 05:22:03.646 PDT [13157] LOG: aborting startup due to startup process failure
2020-05-11 05:22:03.654 PDT [13157] LOG: database system is shut down

Что касается использования файловой системы:

Filesystem Size Used Avail Use% Mounted on
udev 1.5G 0 1.5G 0% /dev
tmpfs 299M 4.8M 294M 2% /run
/dev/mmcblk0p46 5.9G 362M 5.5G 7% /mnt/.rwfs
/dev/disk/by-partlabel/rootfs 362M 362M 0 100% /mnt/.rofs
overlayfs-root 5.9G 362M 5.5G 7% /
tmpfs 1.5G 0 1.5G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup
/dev/mmcblk0p45 976M 2.6M 948M 1% /persist
tmpfs 746M 4.8M 741M 1% /tmp
/dev/mmcblk0p47 19G 45M 19G 1% /srv-internal
/dev/sda4 878G 693G 185G 79% /srv
/dev/sda3 32G 215M 32G 1% /srv/db
/dev/sda2 16G 178M 16G 2% /srv/var

Последний раз полная переустановка/сброс CK2+ помогли, но, думаю, скрипт — это более удобное решение. Можешь прислать его мне тоже?

UI-Team Guest	#11 12.03.2020 21:26:00 sda4 в норме, заполнен на 100% (оставит примерно 32 ГБ свободными). Я напишу в личку, чтобы помочь с разделом /srv/db.

prophoto

Guest

#12

12.03.2020 20:26:00

@UI-Cody Это сообщение было отправлено вам 10.02.2020 в тикете #2265504. Меня просили прислать логи CKG2, но я так и не получил ответа.
root@UniFi-CloudKey-Gen2-Plus:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.5G 0 1.5G 0% /dev
tmpfs 299M 13M 287M 5% /run
/dev/mmcblk0p46 5.9G 131M 5.7G 3% /mnt/.rwfs
/dev/disk/by-partlabel/rootfs 464M 464M 0 100% /mnt/.rofs
overlayfs-root 5.9G 131M 5.7G 3% /tmp
fs 1.5G 0 1.5G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup
tmpfs 746M 64K 746M 1% /tmp
/dev/mmcblk0p45 976M 19M 932M 2% /persist
/dev/mmcblk0p47 19G 45M 19G 1% /srv-internal
/dev/sda4 4.5T 4.5T 31G 100% /srv
/dev/sda3 32G 32G 240K 100% /srv/db
/dev/sda2 16G 57M 16G 1% /srv/var
root@UniFi-CloudKey-Gen2-Plus:~#

prophoto

Guest

#13

12.03.2020 20:23:00

sda3 и sda4 оба заполнены. Кстати, я все еще жду ответа по тикету #2265504. Последний ответ я получил 10 ФЕВРАЛЯ, БОЛЕЕ МЕСЯЦА НАЗАД... Несколько сотрудников поддержки говорили, что «тикет был передан на повышение». Вот только я считаю это чушью.

prophoto Guest	#14 12.03.2020 20:15:00 Да. Я установил значение на 0, потому что не раз движение не записывалось, хотя в кадре явно был человек.

UI-Team Guest	#15 12.03.2020 20:13:00 @prophoto, чтобы уточнить, речь идет именно о заполнении раздела /srv/db, никаких других. Это тот самый раздел, о котором вы говорите на рассматриваемой системе?

UI-Team Guest	#16 12.03.2020 20:12:00 @prophoto — на самом деле я предлагал использовать Stable вместо Enhanced. Ты уменьшал настройку «Минимальное время движения для срабатывания события» до значения меньше стандартных 1 секунды?

prophoto Guest	#17 12.03.2020 19:26:00 @UI-Cody Я проверил этот сайт. Все камеры сейчас настроены на алгоритм движения "Stable". Я не менял это с тех пор, как в прошлом месяце NVR сломался.

prophoto

Guest

#18

12.03.2020 18:34:00

@UI-Cody По этому сайту я бы согласился, что много срабатываний движения, так как камеры находятся в оживленном офисе и на улице с движением транспорта. Судя по твоим словам, мне нужно установить версию 1.13.2 И включить Улучшенный алгоритм движения для каждой камеры, чтобы предотвратить эту ошибку?

UI-Team

Guest

#19

12.03.2020 18:02:00

@prophoto v1.13.2 добавляет возможность переключаться между алгоритмами движения. Для пострадавших пользователей причиной было то, что камеры генерировали слишком много событий из-за использования алгоритма Enhanced motion и при этом не снижали чувствительность, чтобы уменьшить ложные срабатывания. Можешь проверить, используют ли камеры на этом контроллере алгоритм Enhanced?

prophoto Guest	#20 12.03.2020 16:51:00 Кто-нибудь может подтвердить, что версия 1.13.2 действительно решает эту проблему и не даёт разделам заполняться? В прошлом месяце мне пришлось полностью очистить CKG2 у клиента, а теперь он снова вот-вот заполнится.

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