Возможно, стоит попробовать Oracle Java, если вы ещё не используете его.

Привет, я увеличил Java heap до 4096 МБ, а также unifi.xmx и unifi.xms до 4096. С тех пор у меня был всего один случай, когда пришлось перезапустить контроллер. Это случилось, когда один из моих коллег не смог подключить новые точки доступа. Но это был всего лишь один случай почти за месяц.

Привет, заметил ли ты какую-то разницу после того, как увеличил память Java с 1 ГБ до 2 ГБ?

Хочу поделиться нашим опытом решения этой проблемы для тех, кто запускает UniFi контроллер в облаке (или на VPS) и кастомный captive portal на том же сервере, которые взаимодействуют через API-запросы (с помощью PHP, Python и т.д.). Даже при соблюдении всех мер безопасности (fail2ban, проверка, существует ли MAC AP, проверка, есть ли MAC клиента в контроллере и тому подобное) остаётся возможность, что гость слишком часто обновляет страницу входа.

Есть несколько способов решить эту проблему:
- Вести учёт количества попыток входа в собственной базе данных, например MySQL, и выдавать команду block_sta через API, что позволит потом разблокировать пользователя, если человек просто бешено нажимал обновление.
- Создать правило fail2ban, которое блокирует IP после определённого количества попыток. Проблема в том, что клиент нельзя потом разблокировать через интерфейс UniFi контроллера и, что важнее, блокируется IP, из-за чего все остальные клиенты на этом объекте (даже сам AP) теряют связь с UniFi контроллером.
- Создать правило fail2ban, которое после X попыток выдаёт команду block_sta через API, блокируя не IP, а MAC клиента. Здесь сложность в том, что нужно написать кастомное правило.

Мы выбрали третий вариант, потому что он отвечает нашим трём главным требованиям:
- Возможность "откатить" блокировку через софт UniFi контроллера, что исключает блокировку по IP через обычный fail2ban.
- Блокировать только MAC виновника, поскольку наши AP находятся на разных IP и подключаются к контроллеру в облаке через интернет. Если блокировать IP, потеряется связь с самим AP, а это совсем не то, что нам нужно.
- Не хотели внедрять сторонние пакеты, например MySQL, для учёта количества попыток. К тому же PHP (или Python или любой другой серверный код, отвечающий за проверку captive portal) всё равно создаёт нагрузку на CPU и память при каждой проверке. Fail2ban анализирует запросы и может реагировать до того, как следующий запрос дойдёт до основного сервиса.

Эта проблема появляется, когда у клиента работает заражённое ПО и/или он является частью ботнета с частыми исходящими запросами. Дело в том, что человек согласился с условиями и у него есть 3 часа (в нашем случае) доступа в интернет. Заражённое ПО счастливо, ведь оно может связаться с центральным сервером. По истечении 3 часов доступ блокируется, и снова показывается страница входа. Если человека нет рядом, вредоносное ПО продолжит пытаться связаться с ботнет-сервером десятки раз в секунду. Запросы будут попадать на Apache и снова и снова выдавать страницу входа, пока загрузка CPU UniFi контроллера не достигнет 100%, и (в зависимости от того, стоит ли Varnish и сколько доступно оперативной памяти) в итоге сервер может вовсе зависнуть из-за нехватки памяти.

Ты проверял использование памяти? Возможно, у тебя заканчивается память, и процессор перегружается из-за частой очистки мусора.

У меня так же. Дай знать, как работает CentOS. Спасибо.

Изменил строку JVM_MAX_HEAP_SIZE=1024M на JVM_MAX_HEAP_SIZE=2048M в /usr/lib/unifi/bin/unifi.init. Но это тоже не помогло.