Прошло уже 2 месяца — и до сих пор нет никакого решения. Сейчас мы подумываем отказаться от Ubiquiti Wifi и перейти на оборудование других производителей. Поддержка ужасная. Они вообще закрыли заявку, не предложив никакого решения. Потом вернулись с просьбой указать MAC-адрес, КОТОРЫЙ Я УЖЕ ПРЕДОСТАВИЛ В АНАЛИЗЕ ВЫШЕ. Этот процесс был невероятно раздражающим и в итоге полностью бесполезным. Я надеялся, что, вложив время и сделав подробный анализ ошибок, получу полезную обратную связь от Unifi — но нет, только стандартное глупое равнодушное «не-обслуживание». Исходя из нашего опыта, я бы никому не советовал пользоваться Unifi Wifi.

Привет, @UI-Glenn, я пока не создавал тикет в поддержку. Считал, что будет полезнее для всей сообщества поделиться исследованиями и решением здесь, но если ты предпочитаешь вести дальнейшие обсуждения в закрытом формате, можем так сделать. Я тогда могу скопировать ответы от Unifi сюда, чтобы больше людей смогли ими воспользоваться.

Чтобы уточнить: правильно ли я понимаю из твоего вопроса, что Unifi не собираются дальше разбираться с этой проблемой, пока я не создам тикет? Или тебе просто было интересно узнать?

Какие-нибудь мысли от Unifi? Я вложил довольно много времени в отладку этого, стараясь предоставить как можно больше деталей. Готов предоставить дополнительные логи и всё прочее, если нужно, чтобы разобраться в проблеме, но из-за того, сколько времени это уже занимает, у меня начинают спрашивать сверху, почему мы выбрали точки доступа Unifi. Насколько я понимаю, мы исключили AoW как причину этой проблемы, поэтому было бы здорово получить какой-то отклик от Unifi.

@UI-Glenn Какие мысли по этому поводу?

Обновление: похоже, у нас есть решение. В заметках к недавнему обновлению Unifi Controller мы заметили комментарии о снятии ограничений на объём оперативной памяти, которую могут использовать процесс контроллера и MongoDB. В частности, была ссылка на эту страницу: https://help.ui.com/hc/en-us/articles/115005159588-UniFi-Tuning-the-Network-Application-for-a-High-Number-of-UniFi-Devices.

Основываясь на рекомендациях с этой страницы, мы установили параметр "db.mongo.wt.cache_size_default=true" и заметили, что процесс MongoDB стал занимать чуть меньше половины доступной оперативки на сервере (примерно 8 ГБ в нашем случае).

С тех пор все запросы к /api/s/<siteID>/cmd/stamgr выполняются меньше чем за 30 миллисекунд. Так что, держим кулачки — предоставление Mongo большего объёма памяти для кэширования таблиц статистики заметно улучшило производительность. Единственный нюанс — наши сайты сейчас не очень загружены, ведь начало года, поэтому сегодня подключалось меньше 10 клиентов.

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

P.S. @sloofmaster, спасибо тебе за постоянную помощь и поддержку!

Привет, @UI-Glenn,

Пока мы собирали логи, нам также удалось зайти в mongodb через клиент командной строки. Это дало несколько дополнительных подсказок, которые, как нам кажется, могут быть полезны для диагностики.

При входе в MongoDB появляются следующие предупреждения:

Server has startup warnings:  
2023-12-07T19:31:22.728+0000 I STORAGE  [initandlisten]
2023-12-07T19:31:22.728+0000 I STORAGE  [initandlisten] ** ВНИМАНИЕ: Для движка хранения WiredTiger настоятельно рекомендуется использовать файловую систему XFS
2023-12-07T19:31:22.728+0000 I STORAGE  [initandlisten] ** Подробнее: http://dochub.mongodb.org/core/prodnotes-filesystem  
2023-12-07T19:31:23.801+0000 I CONTROL  [initandlisten]
2023-12-07T19:31:23.801+0000 I CONTROL  [initandlisten] ** ВНИМАНИЕ: Контроль доступа к базе данных не включён.
2023-12-07T19:31:23.801+0000 I CONTROL  [initandlisten] ** Чтение и запись данных и конфигураций не ограничены.
2023-12-07T19:31:23.801+0000 I CONTROL  [initandlisten]
2023-12-07T19:31:23.801+0000 I CONTROL  [initandlisten] ** ВНИМАНИЕ: /sys/kernel/mm/transparent_hugepage/enabled установлен в 'always'.
2023-12-07T19:31:23.801+0000 I CONTROL  [initandlisten] ** Рекомендуется поставить 'never'
2023-12-07T19:31:23.801+0000 I CONTROL  [initandlisten]
2023-12-07T19:31:23.801+0000 I CONTROL  [initandlisten] ** ВНИМАНИЕ: soft rlimits слишком низкие. Установлены: 47449 процессов, 524288 файлов. Количество процессов должно быть не меньше 262144 — 0.5 от количества файлов.
2023-12-07T19:31:23.801+0000 I CONTROL  [initandlisten]

Может ли что-то из этого вызывать проблему, которую мы наблюдаем?

Мы взяли следующие основные показатели размера базы данных:  
> show dbs  
ace      0.337GB  
ace_stat 3.249GB  
admin    0.000GB  
config   0.000GB  
local    0.000GB  

Для базы ace_stat размер в 3.2GB — это нормально? Кажется довольно большим.

Мы зашли в базу ace_stat и выполнили вызов .stat() для каждой коллекции. Результаты прикладываю. Не знаю, будет ли это для тебя полезно?

Теперь, когда мы можем подключиться к MongoDB shell, стоит ли включить профилирование (например, db.setProfilingLevel(1, 10000); ) и посмотреть запросы в коллекции system.profile после того, как выполним клиентский деаутентификацию и повторную аутентификацию? Можно ли сделать это на работающем gateway?

Надеюсь, это поможет пролить свет на проблему.

Мне кажется, что Mongo блокирует запись на слишком длительное время.