Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
Утечка памяти в UDM Pro на последней версии ПО?, UniFi Protect
 
Я заметил, что использование памяти на UDMP постепенно растёт в течение 1-3 недель, а затем приложения Network и Protect становятся неработоспособными, пока я не перезагружу устройство. Есть ли идеи, как это исправить? У меня есть 2 камеры и 4 точки доступа. Проблема кажется относительно новой. До нескольких месяцев назад с этим не было никаких проблем. Возможно, это вызвано одним из последних обновлений прошивки.
 
У меня такая же проблема.
 
Какую версию вы используете? На моем UDM SE точно произошла стабилизация в последних EA обновлениях, сейчас работает 5.0.12 EA, но если я правильно помню, надежность начала улучшаться примерно 2 обновления назад.
 
Привет, да, это точно совпадает с тем, что я тоже вижу. Пожалуйста, обязательно сообщи об этом через тикет в поддержку — чем больше случаев они получат, тем выше вероятность, что это получит должное внимание. Я уже отправил им подробную телеметрию, показывающую, что происходит с памятью устройства, но пока они, похоже, игнорируют это, пока консоль полностью не упадёт. Надеюсь, дополнительные отчёты подтолкнут их к расследованию утечки памяти в процессе UniFi Network Controller.
 
Привет, я наблюдаю такое же поведение на своем UDM-Pro уже несколько недель. Оперативная память медленно заполняется до 95–100% и никогда не освобождается, в итоге Web UI становится неответчивым. После проверки через SSH:

suricata (IDS/IPS) остается стабильной на уровне 350–450 МБ оперативной памяти ==> отключение IDS лишь немного снижает использование.

Java процесс (/usr/bin/java -jar /usr/lib/unifi/lib/ace.jar start) продолжает расти со временем, даже если в сети нет никакой серьезной активности.

Процессор работает нормально, и больше никакой процесс не растет так интенсивно.

Это явно указывает на утечку памяти в самом UniFi Network Controller, вероятно в одной из фоновых задач (сбор статистики, топология сети, телеметрия или агрегация DPI).

Когда heap переполняется, Linux начинает использовать swap, UI становится пустым, а устройства временно отключаются от сети до перезагрузки unifi-os.

Отключение IDS замедляет рост, но не останавливает его ==> IDS не является основной причиной проблемы.
 
Да, я отключил его несколько месяцев назад, когда система была перегружена 11 камерами UniFi на Protect. У меня была проблема с сетевым циклом и скоростью портов, которую я решил в выходные, но это было уже после того, как я купил UNVR и перенёс Protect и камеры туда на отдельный VLAN. К счастью, теперь камеры работают стабильно и с сетью всё в порядке. Я пока не включал IDS обратно. Я работаю над настройкой остальной сети, но хотелось бы его вернуть, если это не повлияет на стабильность и не приведёт к сильным потерям в скорости сети.
 
Утечка памяти всё ещё присутствует. Я использую 4.4.5 Unifi OS + 9.5.21 Unifi Network + 6.1.79 Unifi Protect. С отключённым DPI, 8 VLAN'ами, 9 устройствами Unifi (плюс 1 камера G6 bullet и ещё одна камера стороннего производителя) и 85 клиентскими устройствами, при среднем объёме закачек/скачиваний 15-20 Мбит/с, использование памяти за 2 дня выросло с 76% до 94%, а средняя нагрузка на процессор превысила 4. Вся система (особенно 10 камер Nest, которым нужно взаимодействовать с облаком Google) испытывает всевозможные странные проблемы из-за нестабильной работы системы.
 
Я обновился до версии 4.4.3 и заново включил IDS и multicast. Использование памяти стабилизировалось на уровне 84%, но это немного выше, чем было раньше до обновления, когда IDS был отключен (75%).
 
У меня не было утечки памяти, но похоже, что потребление памяти стало меньше, чем раньше. Снижение произошло после того, как я обновил UDM Pro. У меня установлена только сетевая версия.
 
У меня тоже такая проблема. Приходится перезагружать устройство каждые 2 недели, чуть ли не в точности по времени. Перезагрузка UDM-SE решает проблему. Перед тем как интернет отключается, UniFi показывает высокое использование памяти. UniFi OS 5.0.12 Network 10.1.85
 
У меня была такая же проблема, и она исчезла после удаления всех приложений, кроме Network, включая Unifi Protect. Однако использование памяти по-прежнему остаётся высоким.
 
Я бы очень хотел, чтобы мой интернет не отключался каждый второй четверг из-за полного использования памяти.
 
У меня это происходило уже дважды за последние несколько недель. Перезагрузка сервиса UniFi на время исправляет ситуацию. Память всегда занимает много места, но постепенно растёт до уровня, при котором система становится неответчивой:

1D:

1 месяц (падение — это моя последняя перезагрузка из-за этой же проблемы):
 
То же самое — UDM Pro теперь падает каждый день по несколько раз. Отключение IDS мгновенно решает проблему.
 
Я сталкивался с той же проблемой на своём Cloud Gateway Fiber. Suricata вызывает зависание шлюза и требуется перезагрузка, чтобы вернуть его в работу. Это нужно срочно исправить.
 
Если это вызвано утечкой памяти в Suricata (IDS/IPS) или связанном с ней процессе, то добавление большего количества сигнатур для загрузки в памяти через Cybersecure Sub, вероятно, не поможет.
 
Я думал, что это было исправлено, но несколько дней назад мой Dream Router Pro снова стал очень неотзывчивым. Память была около 93%. Поэтому я деактивировал IDS и память тут же упала до 85%. Поскольку я считал, что это всё ещё слишком высокое потребление, я перезагрузил dream machine, и теперь оно скачет между 70-80%. На данный момент похоже, что невозможно работать с включённым IDS, правда? Надеюсь, Ubiquiti по-прежнему следит за этой проблемой и не будет принуждать пользователей выбирать или платить за сервис "CyberSecure Enhanced by Proofpoint and Cloudflare".
 
top - 21:35:37 up 6 days, 22:52, 1 user, load average: 2.90, 3.74, 6.02
Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie
%Cpu(s): 21.2 us, 10.5 sy, 0.0 ni, 65.8 id, 1.4 wa, 0.0 hi, 1.2 si, 0.0 st
MiB Mem: 3946.1 total, 82.3 free, 3301.8 used, 562.0 buff/cache
MiB Swap: 6905.7 total, 5623.7 free, 1282.0 used. 435.0 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
44 root 20 0 0 0 0 S 4.7 0.0 499:31.86 kswapd0

У меня эта же проблема уже какое-то время! kswapd бешено работает, потом отключает IDS, и проблема тут же исчезает. Интересно, занимается ли этим @UI-Team?
 
Со мной то же самое. Отключение обнаружения вторжений сразу же решило проблему. Нагрузка была зашкаливающей. `kswapd` использовал 50% процессора. Теперь все в норме. Правда, график памяти, похоже, показывает ОЗУ и swap вместе. И на самом деле ничего не говорит о реальной нагрузке на систему.

top - 21:35:37 up 6 days, 22:52, 1 user, load average: 2.90, 3.74, 6.02
Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie
%Cpu(s): 21.2 us, 10.5 sy, 0.0 ni, 65.8 id, 1.4 wa, 0.0 hi, 1.2 si, 0.0 st
MiB Mem: 3946.1 total, 82.3 free, 3301.8 used, 562.0 buff/cache
MiB Swap: 6905.7 total, 5623.7 free, 1282.0 used, 435.0 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
44 root 20 0 0 0 0 S 4.7 0.0 499:31.86 kswapd0

Отключил IDS в 21:30. Нагрузка возвращается к норме, примерно 2.5. Каждый раз, когда нагрузка превышает 5 или около того, записи в Protect не загружаются. На звонок у дверей вообще не могу ответить.
 
Я довольно уверен, что IDS не является главной причиной. Я вижу ту же картину медленного роста использования памяти — примерно 8% в неделю, при этом у меня IDS вообще не включен. IDS может усугубить проблему, но похоже, что не вызывает её. Я не знаю, что творится в Ubiquiti. Мы постоянно сталкиваемся с регрессиями, которые серьезно влияют на основную функциональность их оборудования. Вся история с E7, неработающие VPN kill switches, сломанные обнаружения камер и теперь шлюзы, из-за которых вся система становится ненадежной. Баги и уязвимости неизбежны — это жизнь, но кандидаты на релиз, похоже, не проходят нормальное тестирование, выпускаются с внесенными в список серьезными известными проблемами и официально релизятся несмотря на то, что многие люди сообщают об критических багах. Надежность, похоже, рассматривается как желательное дополнение, а не как обязательное требование. Agile-процесс разработки их подвел? Они распыляют усилия со всеми этими новыми релизами? Они завалены техническим долгом, затыкая одну дыру, выкапывая другую?
Страницы: 1 2 След.
Читают тему (гостей: 1)