Спасибо за помощь. Я увеличил оперативную память до 8 ГБ. Вот информация о Java на Debian 8:  
root@wlanc-106:/etc/default# dpkg -l | grep -i java  
ii  java-common                0.52           all           База всех Java-пакетов  
ii  jsvc                      1.0.15-6+deb8u1 amd64         Обертка для запуска Java-приложений как демонов  
ii  libcommons-daemon-java     1.0.15-6+deb8u1 all           Библиотека для запуска Java-приложений как демонов  
ii  libv8-3.14.5              3.14.5.8-8.1    amd64         Движок JavaScript V8 — библиотека времени выполнения  
ii  oracle-java8-installer    8u131-1~webupd8~2 all          Oracle Java™ Development Kit (JDK) 8  
ii  oracle-java8-set-default  8u131-1~webupd8~2 all          Устанавливает Oracle JDK 8 как Java по умолчанию  
 
root@wlanc-106:/etc/default# cat unifi  
JAVA_HOME=/usr/lib/jvm/java-8-oracle  
 
top - 15:06:55 up 20 min, 1 user, load average: 3.28, 3.35, 2.54  
Задачи: 118 всего, 1 запущена, 117 спят, 0 остановлены, 0 зомби  
%CPU: 21.0 пользователь, 0.3 система, 0.0 nice, 76.8 простаивает, 1.1 ожидание ввода-вывода, 0.0 аппаратные прерывания, 0.8 программные прерывания, 0.0 виртуализация  
Память: всего 8197260 Кб, используется 3174596 Кб, свободно 5022664 Кб, буферы 12096 Кб  
Своп: всего 471036 Кб, используется 0 Кб, свободно 471036 Кб. Кешировано 1115768 Кб  
 
Может, стоит настроить Mongo и Java?

Даже если оперативной памяти кажется достаточно, возможно, увеличение её объёма позволит Linux использовать «свободную» память как кэш диска или буферы и, весьма вероятно, улучшит общую производительность машины. Я бы сначала попробовал удвоить или утроить объём RAM, прежде чем увеличивать количество процессоров.

Если распределить AP между несколькими сайтами на одном контроллере, скорее всего, возникнет та же проблема. Если же установить несколько контроллеров, например, используя Cloud Key на каждом сайте, производительность контроллера на каждом из них улучшится, потому что нагрузка будет меньше. Но настройка с несколькими сайтами и контроллерами создаёт свои собственные сложности в управлении. Можно также выделить вашему текущему контроллеру больше ресурсов. На какой железе он у вас работает? Можете добавить оперативной памяти (только не забудьте поправить init-скрипт, чтобы при запуске запрашивалась нужная сумма), а если у вас медленный диск, лучше заменить его на SSD или добавить ещё шпинделей — это поможет справиться с объёмами данных от ваших AP и клиентов. Если узким местом является процессор, скорее всего, придётся менять сервер, если только CPU нельзя заменить или улучшить.

Верно — сначала нужно обновиться до версии 3.2.10, затем перейти на 4, а потом на 5: https://help.ubnt.com/hc/en-us/articles/220340647-UniFi-Upgrading-from-v2-x-to-v4-x-or-later-

Да, как уже советовали другие, давно пора обновить контроллер! Выключите автоматическое обновление прошивки перед обновлением, и риск будет минимальным, если вы не меняете прошивку на своих устройствах (хотя в текущей прошивке для большинства AP исправлено много ошибок). Кстати, всегда можно сделать резервную копию файлов прошивки в вашем текущем контроллере и сохранить их на случай отката. Очистка базы данных теперь встроена прямо в графический интерфейс контроллера:

Возможно, здесь особо и снижать нечего. 1900 AP — это ОГРОМНЫЙ сценарий, и хотя ты не упомянул, я уверен, что у тебя должно быть ОЧЕНЬ МНОГО устройств, а это генерирует КУЧУ логов в базе данных. Попробуй уменьшить параметр days в prune.js до чего-то действительно маленького, например, до 30 дней, и посмотри, уменьшится ли размер. Должен уменьшиться. Кстати, какое значение days было у тебя, когда ты запускал prune.js на MongoDB?

@ks99

Ты не забыл изменить скрипт, чтобы он вышел из режима «пробного запуска»? В инструкциях на https://help.ubnt.com/hc/en-us/articles/204911424-UniFi-How-to-Remove-Prune-Older-Data-and-Adjust-Mongo-Database-Size написано: «Предполагая, что вы используете nano для редактирования файла, управляйте текстом с помощью стрелок. Измени var days=7; чтобы задать, сколько дней данных хранить; и поменяй var dryrun=true; на var dryrun=false; чтобы скрипт действительно очищал базу данных, а не просто делал тестовый прогон.» Я сам никогда не пользовался этим скриптом, но насколько я понимаю, изначально он не вносит изменений, если его не модифицировать.