Всем привет! Обновил несколько UAP Outdoor+ и старых UAP indoor с версии до 3.9.15.8011 (текущая стабильная версия для загрузки). Цель — решить проблему с UAP Outdoor+, которые через примерно 18 дней работы почти полностью забивают память и просто отключаются. Если ловлю их с мегабайтом или двумя свободной памяти (в устройствах 64 МБ ОЗУ), то могу зайти по SSH и перезагрузить их или сделать это через контроллер. Если же ситуация сильно усугубляется, устройства перестают отвечать и приходится физически выключать и включать питание.
Обратил внимание, что в changelog к 3.9.15.8011 написано, что исправили небольшой утечка, но, судя по всему, проблемы с утечками всё еще есть. Сегодня заметил точку доступа без клиентов, у которой после всего лишь 12 дней работы занято 85% памяти — после свежей перезагрузки память снижается до 75%. У других уже по 86% и 87% занято, и, думаю, по мере приближения к 18 дням загрузка памяти будет расти.
Основной виновник — процесс «mcad». На точке доступа, которая работает 12 дней, виртуальный размер этого процесса вдвое больше, чем на только что перезагруженном устройстве. Вот вывод сравнения:
Точка доступа с 12 днями аптайма:
BZ.v3.9.15# uptime
17:54:46 up 12 days, 4:13, load average: 0.00, 0.00, 0.00
BZ.v3.9.15# ps
...
1359 admin 13064 S /bin/mcad
...
Память: всего 62376 КБ, занято 54152 КБ, свободно 8224 КБ.
Размер процесса /bin/mcad — 13 МБ виртуальной памяти.
Тот же AP после свежей перезагрузки:
BZ.v3.9.15# uptime
17:55:32 up 1:40, load average: 0.00, 0.00, 0.00
BZ.v3.9.15# ps
...
1359 admin 7276 S /bin/mcad
...
Память: всего 62376 КБ, занято 47004 КБ, свободно 15372 КБ.
/process /bin/mcad — всего 7 МБ. Значит, за 12 дней ушло 6 МБ памяти!
Предсказываю, что придется перезагружать эти устройства примерно каждые 12 дней, иначе память будет расти до такой степени, что они не смогут запустить процесс SSH, а также начнут теряться heartbeat'ы и AP будут пропадать и появляться в контроллере UniFi.
Думаю, открою тикет в поддержку и приложу ссылку на этот пост. Раньше можно было получать сотни дней непрерывной работы, но похоже, что эти времена прошли, пока mcad продолжает расти из-за какой-то утечки.
У меня есть приличный опыт работы с embedded Linux устройствами, может попробую присоединиться к делу и помочь с отладкой. Спасибо!
Обратил внимание, что в changelog к 3.9.15.8011 написано, что исправили небольшой утечка, но, судя по всему, проблемы с утечками всё еще есть. Сегодня заметил точку доступа без клиентов, у которой после всего лишь 12 дней работы занято 85% памяти — после свежей перезагрузки память снижается до 75%. У других уже по 86% и 87% занято, и, думаю, по мере приближения к 18 дням загрузка памяти будет расти.
Основной виновник — процесс «mcad». На точке доступа, которая работает 12 дней, виртуальный размер этого процесса вдвое больше, чем на только что перезагруженном устройстве. Вот вывод сравнения:
Точка доступа с 12 днями аптайма:
BZ.v3.9.15# uptime
17:54:46 up 12 days, 4:13, load average: 0.00, 0.00, 0.00
BZ.v3.9.15# ps
...
1359 admin 13064 S /bin/mcad
...
Память: всего 62376 КБ, занято 54152 КБ, свободно 8224 КБ.
Размер процесса /bin/mcad — 13 МБ виртуальной памяти.
Тот же AP после свежей перезагрузки:
BZ.v3.9.15# uptime
17:55:32 up 1:40, load average: 0.00, 0.00, 0.00
BZ.v3.9.15# ps
...
1359 admin 7276 S /bin/mcad
...
Память: всего 62376 КБ, занято 47004 КБ, свободно 15372 КБ.
/process /bin/mcad — всего 7 МБ. Значит, за 12 дней ушло 6 МБ памяти!
Предсказываю, что придется перезагружать эти устройства примерно каждые 12 дней, иначе память будет расти до такой степени, что они не смогут запустить процесс SSH, а также начнут теряться heartbeat'ы и AP будут пропадать и появляться в контроллере UniFi.
Думаю, открою тикет в поддержку и приложу ссылку на этот пост. Раньше можно было получать сотни дней непрерывной работы, но похоже, что эти времена прошли, пока mcad продолжает расти из-за какой-то утечки.
У меня есть приличный опыт работы с embedded Linux устройствами, может попробую присоединиться к делу и помочь с отладкой. Спасибо!