На этой неделе я получил несколько жалоб от клиентов, что сигнал Wi-Fi был плох в некоторых зонах их площадок. После того, как я нашёл один или несколько отключённых AP в их сетях и сделал перезагрузку питания (выключил/включил PoE-инжектор или порт PoE свитча), сигнал восстанавливался.
После дальнейшего анализа я точно понял, что сталкиваюсь с каким-то утечкой памяти на AP, которая, скорее всего, связана с их падением примерно через 20-22 дня работы без перерыва.
Так как я наблюдаю это на разных площадках, я не смог определить, связано ли это с какой-то конкретной функцией на этой площадке. На самом деле, я видел площадки с несколькими AP, где некоторые показывают плохое поведение, а другие — нет (тот же модель AP, абсолютно одинаковые настройки). Были площадки, где AP с самой высокой нагрузкой показывал себя без утечки памяти, а другие с меньшим трафиком — с утечкой, так что это не связано с трафиком или количеством пользователей (настройки одинаковые на всех AP).
Единственное действительно стабильное наблюдение — устройства Gen1 НЕ показывают поведение с утечкой памяти. Их использование памяти довольно высокое сразу после перезагрузки — около 80%, но оно остаётся стабильным в течение недель работы без каких-либо явных признаков утечки.
На этих AP с возможной утечкой памяти устройство продолжает отвечать на ping в сети (то есть не происходит полного зависания), но при этом SSH-доступ уже не работает, вообще ничего не работает. Это немного отличается от другой ошибки, о которой я сообщал ранее — там AP отключались от контроллера, но оставались доступны по SSH для перезагрузки из командной строки. В случае с утечкой памяти помочь может только перезагрузка питания.
(Мой предыдущий багрепорт BUG: Timeout waiting for vap to stop)
Вот пример AP с падением из-за утечки памяти... он отвечает на пинг, но SSH-доступ не даёт:
[root@unifi ~]# ping -c 5 10.7.1.117
PING 10.7.1.117 (10.7.1.117) 56(84) байт данных.
64 байт от 10.7.1.117: icmp_seq=1 ttl=62 время=13.2 мс
64 байт от 10.7.1.117: icmp_seq=2 ttl=62 время=12.3 мс
64 байт от 10.7.1.117: icmp_seq=3 ttl=62 время=12.2 мс
64 байт от 10.7.1.117: icmp_seq=4 ttl=62 время=12.4 мс
64 байт от 10.7.1.117: icmp_seq=5 ttl=62 время=12.0 мс
[root@unifi ~]# ssh -o ConnectTimeout=30 admin@10.7.1.117
Connection timed out during banner exchange
[root@unifi ~]#
Все устройства, с которыми я столкнулся в проблемах с утечкой памяти (это видно по графикам производительности в контроллере), — это в основном Gen2 UniFi AC Lite с прошивкой 4.0.54. Некоторые с гостевым порталом, некоторые без. Некоторые с включённым SSID 802.1x (WPA2 Enterprise), некоторые без. Некоторые с гостевым SSID (без портала), некоторые без. Я так и не смог найти какую-то функцию, чётко связанную с этим, особенно учитывая, что на одной площадке у нескольких AP одного и того же типа и с одинаковыми настройками одни показывают проблему, а другие — нет.
Прикладываю несколько скриншотов, где чётко видно проблему (утечку памяти)... и как AP полностью падает, до такой степени, что нужна перезагрузка питания.
site 01 – Gen2 AP – утечка памяти явно видна (красная линия добавлена мной — это тот AP, по которому выше приводились тесты ping/ssh)
site 01 – Gen2 AP – использование памяти 7 дней назад (уже было высокое)
site 01 – Gen2 AP – использование памяти через 7 дней после предыдущего скриншота
site 01 – AP Gen2 – другой AP с той же площадки, показывающий похожее поведение с утечкой памяти
site 01 – AP Gen2 – другой AP с той же площадки, не показывающий утечки памяти
site 02 – AP Gen2 – поведение с утечкой памяти
site 03 – AP Gen1 – *нет* поведения с утечкой памяти
site 03 (тот же с предыдущего скриншота) – AP Gen2 – утечка памяти присутствует
site 03 – AP Gen2 – утечка памяти присутствует
(и теперь 3 разных AP с 3 разных площадок, все Gen1, у них утечка памяти никогда не проявляется)
После дальнейшего анализа я точно понял, что сталкиваюсь с каким-то утечкой памяти на AP, которая, скорее всего, связана с их падением примерно через 20-22 дня работы без перерыва.
Так как я наблюдаю это на разных площадках, я не смог определить, связано ли это с какой-то конкретной функцией на этой площадке. На самом деле, я видел площадки с несколькими AP, где некоторые показывают плохое поведение, а другие — нет (тот же модель AP, абсолютно одинаковые настройки). Были площадки, где AP с самой высокой нагрузкой показывал себя без утечки памяти, а другие с меньшим трафиком — с утечкой, так что это не связано с трафиком или количеством пользователей (настройки одинаковые на всех AP).
Единственное действительно стабильное наблюдение — устройства Gen1 НЕ показывают поведение с утечкой памяти. Их использование памяти довольно высокое сразу после перезагрузки — около 80%, но оно остаётся стабильным в течение недель работы без каких-либо явных признаков утечки.
На этих AP с возможной утечкой памяти устройство продолжает отвечать на ping в сети (то есть не происходит полного зависания), но при этом SSH-доступ уже не работает, вообще ничего не работает. Это немного отличается от другой ошибки, о которой я сообщал ранее — там AP отключались от контроллера, но оставались доступны по SSH для перезагрузки из командной строки. В случае с утечкой памяти помочь может только перезагрузка питания.
(Мой предыдущий багрепорт BUG: Timeout waiting for vap to stop)
Вот пример AP с падением из-за утечки памяти... он отвечает на пинг, но SSH-доступ не даёт:
[root@unifi ~]# ping -c 5 10.7.1.117
PING 10.7.1.117 (10.7.1.117) 56(84) байт данных.
64 байт от 10.7.1.117: icmp_seq=1 ttl=62 время=13.2 мс
64 байт от 10.7.1.117: icmp_seq=2 ttl=62 время=12.3 мс
64 байт от 10.7.1.117: icmp_seq=3 ttl=62 время=12.2 мс
64 байт от 10.7.1.117: icmp_seq=4 ttl=62 время=12.4 мс
64 байт от 10.7.1.117: icmp_seq=5 ttl=62 время=12.0 мс
[root@unifi ~]# ssh -o ConnectTimeout=30 admin@10.7.1.117
Connection timed out during banner exchange
[root@unifi ~]#
Все устройства, с которыми я столкнулся в проблемах с утечкой памяти (это видно по графикам производительности в контроллере), — это в основном Gen2 UniFi AC Lite с прошивкой 4.0.54. Некоторые с гостевым порталом, некоторые без. Некоторые с включённым SSID 802.1x (WPA2 Enterprise), некоторые без. Некоторые с гостевым SSID (без портала), некоторые без. Я так и не смог найти какую-то функцию, чётко связанную с этим, особенно учитывая, что на одной площадке у нескольких AP одного и того же типа и с одинаковыми настройками одни показывают проблему, а другие — нет.
Прикладываю несколько скриншотов, где чётко видно проблему (утечку памяти)... и как AP полностью падает, до такой степени, что нужна перезагрузка питания.
site 01 – Gen2 AP – утечка памяти явно видна (красная линия добавлена мной — это тот AP, по которому выше приводились тесты ping/ssh)
site 01 – Gen2 AP – использование памяти 7 дней назад (уже было высокое)
site 01 – Gen2 AP – использование памяти через 7 дней после предыдущего скриншота
site 01 – AP Gen2 – другой AP с той же площадки, показывающий похожее поведение с утечкой памяти
site 01 – AP Gen2 – другой AP с той же площадки, не показывающий утечки памяти
site 02 – AP Gen2 – поведение с утечкой памяти
site 03 – AP Gen1 – *нет* поведения с утечкой памяти
site 03 (тот же с предыдущего скриншота) – AP Gen2 – утечка памяти присутствует
site 03 – AP Gen2 – утечка памяти присутствует
(и теперь 3 разных AP с 3 разных площадок, все Gen1, у них утечка памяти никогда не проявляется)