Ошибки heartbeat USG каждую неделю или чаще при высоком использовании ресурсов

Ошибки heartbeat USG каждую неделю или чаще при высоком использовании ресурсов, UniFi Network

dlinkoz

Guest

17.05.2017 14:00:00

С тех пор как я обновился до версии 4.3.41.4975503, мой USG становится нестабильным каждые 4-6 дней. Вот как выглядело время без перезагрузок за последний месяц (из-за необходимости перезапускать устройство, чтобы всё стабилизировать):

Когда начинаются пропуски heartbeat, они случаются с интервалом в 5-15 минут. При этом нагрузка на ресурсы устройства тоже скачет без видимой причины. Если посмотреть на утреннюю перезагрузку, можно заметить чрезмерное использование CPU без реальных причин:

Также это отражается и в системной нагрузке:

Кто-нибудь ещё сталкивался с такой проблемой? Я полностью сбрасывал настройки, не использую json-файлы, вся конфигурация идёт напрямую с контроллера и не менялась уже год, но проблема появилась примерно в последний месяц-два (то есть после выхода этой версии прошивки USG).

dlinkoz

Guest

03.07.2017 21:32:00

Варианты rrdtool, судя по другим сообщениям. Я использую cacti, некоторые могут применять другие инструменты, но большинство всё равно работают с rrdtool в основе. По сути, USG — это линукс-бокс, так что многие те же графики доступны.

JamieGriffiths Guest	#3 03.07.2017 21:20:00 Немного в сторону — а как вы вообще строите графики по этим данным? Каким источником данных и каким приложением для построения графиков вы пользуетесь? Заранее спасибо.

dlinkoz Guest	#4 03.07.2017 11:31:00 7 дней без утечки памяти, новая бета-версия прошивки, похоже, решила проблему.

markve

Guest

14.06.2017 09:57:00

С прошлой ночи такая же проблема наблюдается и в моей среде. Сейчас утечек памяти не вижу, но с вчерашнего дня сильно загружен процессор:

На консоли шлюза появляются те же ошибки:
Message from syslogd@UniFiGateway at Jun 14 11:48:47 ...000 {"tunnel_info":{},"__error":""}
Моя конфигурация:
Controller (Key) v5.5.14
UniFi Security Gateway 3P: v4.3.41.4975503
У меня настроен один VPN-сайт-сайт с Azure и активная VPN-подключение пользователя L2TP с аутентификацией через RADIUS на Windows NPS сервере.

doyleb Guest	#6 13.06.2017 01:10:00 Жду исправления! Только что опять случилось на тех же двух устройствах USG, так что, видимо, придётся перезагружать их как минимум раз в две недели.

mblecha Guest	#7 11.06.2017 18:39:00 Это известная проблема, о которой обсуждают в этой теме: https://community.ui.com/questions/a20f06f5-6f71-4bb3-b5f1-a91b184fb421. Мы ждём релиз, который UBNT тестировали в альфа-версии.

dlinkoz Guest	#8 11.06.2017 14:21:00 Похоже, это всё ещё связано с туннелями. Вот сообщение из консоли, которое я получаю, если остаюсь подключённым во время одного из его "приступов": Message from syslogd@GameRoomUSG at Jun 11 09:09:10 ...000 {"tunnel_info":{},"__error":""}

dlinkoz

Guest

11.06.2017 14:04:00

Ссылки на /tmp, похоже, отвлекают внимание, эта файловая система полностью доступна:
admin@GameRoomUSG:~$ touch /tmp/test
admin@GameRoomUSG:~$ ls -l /tmp
total 0
drwxrwxr-x 2 root vyattacf 40 Jun 11 09:00 changes_only_15ea095909b5714074c0405c78
drwxrwxr-x 2 root vyattacf 40 Jun 11 08:53 changes_only_189a002a2780ee944d7eb717e3
drwxrwxr-x 2 root vyattacf 40 Jun 11 08:41 changes_only_4fb897d24a7b917e48bf89550d
drwxrwxr-x 2 root vyattacf 40 Jun 11 08:56 changes_only_70daf07a38adec1aadedfa13fa
drwxrwxr-x 2 root vyattacf 40 Jun 11 08:49 changes_only_95b3c9dd88d3167231484af792
drwxrwxr-x 2 root vyattacf 40 Jun 11 08:45 changes_only_be66985290bc5418aeaf7678f9
srwxrwxrwx 1 root root 0 Jun 5 13:28 openvpn-mgmt-intf-
rw-r--r-- 1 admin users 0 Jun 11 09:01 tests
rwxrwx--- 1 root vyattacf 0 Jun 5 13:00 ubnt.socket.cfg
dsrwxrwx--- 1 root www-data 0 Jun 8 15:00 ubnt.socket.cli
srw-rw---- 1 root users 0 Jun 8 15:00 ubnt.socket.plat
dsrwxrwx--- 1 root www-data 0 Jun 8 15:00 ubnt.socket.stats
dsrwxrwx--- 1 root www-data 0 Jun 8 15:00 ubnt.socket.sysd

И эти каталоги changes_only_xxxxx создаются и обновляются, похоже, в связи с отключениями от контроллера.

dlinkoz

Guest

#10

04.06.2017 07:27:00

Похоже, что наблюдается утечка памяти, и это, судя по всему, связано с site-to-site туннелями (кажется, все, кто высказывался, подтвердили, что у них есть такие туннели). По этим графикам видно, что раньше использование памяти было относительно стабильным. Однако за последний месяц-два оно стало очень скачкообразным, и проблемы возникают, когда потребление приближается к высоким значениям (хотя я бы не назвал это критичным). Очевидно, что резкие падения связаны с перезагрузкой.

doyleb

Guest

#11

02.06.2017 03:52:00

Я начал получать уведомления о сбоях несколько раз в день для одного из своих USG и видел в журнале одни и те же сообщения прямо перед временем уведомлений о сбоях, которые повторялись пару минут. perl_wrapper: 1 попытка открытия в /usr/bin/perl_wrapper.pl строка 58. {"tunnel_info":{},"__error":""} mca-monitor: mca-client.service(): Не удалось отправить запрос в '/tmp/.mcad' — 'Ресурс временно недоступен'. Сообщения с ключами _lifetime и _expire появляются непрерывно. Пока не изучал прошлые логи достаточно, чтобы сказать, как долго это длится. Я перезагрузил устройство с командной строки, и проблема прекратилась. На следующее утро после перезагрузки этого устройства другой USG с VPN site-to-site, подключённый к первому, начал испытывать ту же проблему и в журналах появились те же сообщения. Перезагрузил — снова всё в порядке. Сейчас уже почти две недели без инцидентов, но посмотрим. Первый USG использует config.gateway.json, который добавляет две таблицы статических маршрутов и два правила модификации фаервола для политики маршрутизации. Второй такого не делает. Cloud Key — 0.6.4 Unifi — 5.4.16-9234 USG — 4.3.41.4975503

di3 Guest	#12 02.06.2017 02:11:00 @dlinkoz Мне кажется, что файловая система USG повреждена: есть проблемы с доступом к каталогу "/tmp/", она выдаёт ошибки при чтении "/config", из-за чего, скорее всего, демон mcad находится в таком нестабильном состоянии. Это происходит, когда USG не удаётся получить доступ к сети (предполагаю, обновление DHCP для вашего интернет-соединения), и поэтому ситуация повторяется регулярно (вот почему у вас меняется статистика с ростом и падением нагрузки на RAM/CPU). Раньше, если не учитывать аппаратные проблемы (например, со стореджем на USG), это могло быть неплохой идеей. Возможно, попробуйте: - Принудительно обновить USG до последней производственной прошивки; - Принудительно провести провиженинг ещё раз, чтобы убедиться; - А затем проверить в /var/log/messages, что демон mcad стабилен.

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