Спасибо за заботу. В моей установке стоит последняя версия log4j, я обновил её вручную. Проблема в том, что база данных не справляется с объёмом передаваемых данных. Это происходит только в определённые дни и часы недели из-за внезапного увеличения числа клиентов, которые подключаются все одновременно. В результате контроллер оказывается завален большим количеством информационных пакетов. Во время пиковых нагрузок я получаю более 10 Мбит/с трафика на TCP/порт 8080. Просто из любопытства, какие у вас характеристики железа? И сколько у вас устройств прямо сейчас?

Хочу отметить, что я решил эту проблему у себя. Проблема, с которой я столкнулся, не была связана с неправильной настройкой контроллера Unifi. Оказалось, что мои системы подвергались атаке из-за уязвимости log4j. Вот почему, когда они выходили в онлайн, сразу же перегружались. Как только Unifi исправили проблему с log4j, моя проблема исчезла. Сейчас мой контроллер работает очень стабильно.

Увеличил inform_stat.thread_queue_size до 24000, но это не помогло. Сейчас тестирую 48k. inform.num_thread=20000

Ваши характеристики не подходят для такого количества устройств, особенно если вы планируете увеличить их число до 7000. Ваш файл system.properties потребуется доработать.

Что-то странное у меня с этим было. Все время глючило, а потом, странным образом, после перезагрузки контроллера начало работать. Я ничего не трогал. Странно. Видимо, понадобилось пару дней, чтобы система разобралась со своим бредом.

Я создал заявку в техподдержку Ubiquiti.

Я работаю с более чем 200 000 устройств Unifi на тысячах контроллеров и тысячах площадок и пока не встречал такого поведения на больших контроллерах с версиями 6.4 или 6.5, так что это явно исключение. Вы не сможете понизить версию контроллера без использования старой резервной копии (6.4). Если хотите, пришлите мне информацию — я попробую воспроизвести проблему или даже помочь с её размещением.

Попробуйте добавить db.mongo.wt.cache_size=4096 unifi.xss=4096 Remove db.mongo.wt.cache_size_default=true unifi.G1GC.enabled=true Сколько устройств подключено?

Конечно, сервер EPYC 7401, на котором стоит Server 2019 Standard с 128 ГБ ECC RAM и NVME SSD в RAID 0 для Unifi, при этом каждая виртуальная машина работает на своём выделенном массиве хранения. Виртуальная машина для контроллера Unifi с 16 ядрами и 40 ГБ оперативной памяти, выделена Windows 10 PRO JAVA 8-311. Всё работало нормально с версией 6.4 (ну, по крайней мере какое-то время — через неделю она начала барахлить), а 6.5 постоянно глючит. Даже пробовал mongo 3.6. У меня есть контроллеры на Ubuntu — стабильность SDN не меняется. Ubuntu обычно вызывает больше проблем, чем Windows, особенно с 10GB сетевыми картами. Вот настройки, которые я использовал:  
db.mongo.connections_per_host=250  
db.mongo.threads_multiplier=10  
db.mongo.wt.cache_size_default=true  
debug.device=warn  
debug.mgmt=warn  
debug.sdn=warn  
debug.system=warn  
inform.max_keep_alive_requests=3500  
inform.num_thread=4000  
inform_stat.thread_queue_size=6000  
is_default=false  
unifi.G1GC.enabled=true  
unifi.xms=25600  
unifi.xmx=32768  

Ничто, кроме времени работы, не влияет на стабильность — примерно через 10-15 минут появляется постоянная ошибка:  
[2021-12-04T11:03:35,231] <stat-processor> WARN dev - Inform stat queue capacity exceeded

Моя главная проблема — я построил новый RV-парк с новым контроллером версии 6.5.53, пока не понял, что он постоянно глючит. Теперь мне придётся или использовать 6.5.53 с новым объектом, или заново подключать всё через 6.4.54, которая была намного стабильнее.