Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Вызов API к /api/s/<siteID>/cmd/stamgr очень медленный (больше 60 секунд), wifiman
 
Пожалуйста, пришлите текст для перевода.
 
Привет, @bafta_benj! Судя по тикету, мы ждём от вас информации. Не упустил ли я что-то?
 
Прошло уже 2 месяца — и до сих пор нет никакого решения. Сейчас мы подумываем отказаться от Ubiquiti Wifi и перейти на оборудование других производителей. Поддержка ужасная. Они вообще закрыли заявку, не предложив никакого решения. Потом вернулись с просьбой указать MAC-адрес, КОТОРЫЙ Я УЖЕ ПРЕДОСТАВИЛ В АНАЛИЗЕ ВЫШЕ. Этот процесс был невероятно раздражающим и в итоге полностью бесполезным. Я надеялся, что, вложив время и сделав подробный анализ ошибок, получу полезную обратную связь от Unifi — но нет, только стандартное глупое равнодушное «не-обслуживание». Исходя из нашего опыта, я бы никому не советовал пользоваться Unifi Wifi.
 
Создан запрос в службу поддержки: #4121112
 
Привет, @UI-Glenn, я пока не создавал тикет в поддержку. Считал, что будет полезнее для всей сообщества поделиться исследованиями и решением здесь, но если ты предпочитаешь вести дальнейшие обсуждения в закрытом формате, можем так сделать. Я тогда могу скопировать ответы от Unifi сюда, чтобы больше людей смогли ими воспользоваться.

Чтобы уточнить: правильно ли я понимаю из твоего вопроса, что Unifi не собираются дальше разбираться с этой проблемой, пока я не создам тикет? Или тебе просто было интересно узнать?
 
Привет, @bafta_benj, у тебя есть тикет в поддержку по этому поводу?
 
Какие-нибудь мысли от Unifi? Я вложил довольно много времени в отладку этого, стараясь предоставить как можно больше деталей. Готов предоставить дополнительные логи и всё прочее, если нужно, чтобы разобраться в проблеме, но из-за того, сколько времени это уже занимает, у меня начинают спрашивать сверху, почему мы выбрали точки доступа Unifi. Насколько я понимаю, мы исключили AoW как причину этой проблемы, поэтому было бы здорово получить какой-то отклик от Unifi.
 
@bafta_benj К вашему сведению: команда второго подтверждения управляется опцией APP_DOUBLE_AUTH в вашем файле .env для приложения. Можете проверить, что будет, если отключить ее; по крайней мере, это гарантирует, что второе подтверждение не будет выполняться.
 
@UI-Glenn Какие мысли по этому поводу?
 
None
 
Обновление: похоже, у нас есть решение. В заметках к недавнему обновлению 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?

Надеюсь, это поможет пролить свет на проблему.
 
@UI-Glenn У нас готовы файлы, которые нужно отправить тебе. Как лучше всего передать их тебе безопасно? Не мог бы ты выложить публичный PGP-ключ, чтобы мы могли зашифровать данные?
 
Мне кажется, что Mongo блокирует запись на слишком длительное время.
 
Привет, @bafta_benj @slooffmaster, судя по первому беглому просмотру, мы не видим ничего, что могло бы занять очень много времени. Есть несколько вызовов к базе данных, которые кажутся простыми. Нам понадобятся файл поддержки и логи server.log, mongod.log, access.log, gc.log для дальнейшего анализа.
 
@UI-Glenn, можно привлечь твоё внимание к этому? Также посмотри, пожалуйста, мой личный сообщение.
Страницы: 1
Читают тему (гостей: 1)