Сколько RAM нужно для LibreNMS

MAATRIX

LibreNMS — удобный инструмент: поставил, дал community-строку SNMP, и он сам находит соседей по CDP/LLDP, рисует топологию и копит графики. Проблема начинается на этапе выбора сервера: официальная документация говорит расплывчато — «2 ГБ для небольшой инсталляции», а через полгода после подключения третьего офиса опрос начинает опаздывать, MySQL ест всю память, и сервер уходит в своп. Разберём, из чего реально складывается потребление RAM у LibreNMS и как посчитать запас заранее, а не по факту падения.

Из чего складывается потребление памяти

LibreNMS — это не один процесс, а связка из нескольких сервисов, и память нужно закладывать под каждый:

• PHP-FPM — обслуживает веб-интерфейс и API. Каждый воркер держит по 30-80 МБ в зависимости от количества одновременных пользователей и активности дашбордов с графиками.
• MySQL/MariaDB — самый тяжёлый компонент. Хранит устройства, порты, alert-правила и (если не вынесли метрики в InfluxDB) часть временных рядов. Именно СУБД съедает основную долю RAM через innodb_buffer_pool_size.
• Poller — процесс, который ходит по SNMP и складывает данные. Работает пачками (batch), каждый воркер поллера — это отдельный PHP-процесс, недолгий, но прожорливый на пике.
• RRDtool (если не переключились на InfluxDB/Prometheus) — сам по себе лёгкий, но активно грузит дисковый кэш, а он тоже съедает страничный кэш ОС, который де-факто конкурирует за ту же память.
• Redis/Memcached — опционально, но настоятельно рекомендуется LibreNMS для кэширования конфигурации устройств и снижения нагрузки на MySQL. Обычно 100-500 МБ, зависит от числа устройств.
• Дискавери и billing-модули — если включены, добавляют периодическую нагрузку, заметную по памяти только на крупных инсталляциях (от пары сотен устройств).

Итого RAM для LibreNMS — это не «память самого приложения», а сумма аппетитов PHP, MySQL, кэша и дисковой подсистемы, которые между собой конкурируют за одну и ту же физическую память сервера.

Сколько RAM нужно в зависимости от числа устройств

Точных цифр без вашей топологии не даст никто — зависит от количества портов на устройство, интервала опроса и того, сколько людей одновременно смотрит дашборды. Но по практике эксплуатации небольших и средних инсталляций можно ориентироваться на такие вилки (именно ориентир, не гарантия — на вашем железе цифры могут отличаться на 20-30%):

Ключевая оговорка: таблица считает «типовое» устройство с 10-40 портами и стандартным интервалом опроса в 300 секунд. Если у вас в основном ядерные свитчи на 48-96 портов или вы опрашиваете чаще (120 или 60 секунд), закладывайте следующую строку таблицы уже при половинном количестве устройств — нагрузка растёт не по числу узлов, а по числу опрашиваемых OID в единицу времени.

MySQL/MariaDB — самый прожорливый компонент

На старте большинство инсталляций LibreNMS упираются именно в СУБД, а не в поллер. Дефолтные настройки MariaDB рассчитаны на универсальный случай и для мониторинга сети не годятся — буфер слишком маленький, и база начинает писать на диск чаще, чем нужно.

Минимальный набор правок в /etc/mysql/mariadb.conf.d/50-server.cnf (или /etc/mysql/conf.d/librenms.cnf, если выносите в отдельный файл):

[mysqld]
innodb_buffer_pool_size = 2G          # 40-60% от RAM, выделенной под MySQL
innodb_buffer_pool_instances = 2
innodb_flush_log_at_trx_commit = 2    # компромисс скорость/надёжность для метрик
innodb_file_per_table = 1
innodb_io_capacity = 1000             # выше на NVMe, ниже на HDD/сетевых дисках
max_connections = 60

Официальная рекомендация LibreNMS — держать innodb_buffer_pool_size в районе 50% от RAM, выделенной под MySQL, но не выше объёма реальных данных в таблицах (иначе вы просто резервируете память впустую). Проверить текущий размер данных:

mysql -e "SELECT table_schema AS db, ROUND(SUM(data_length+index_length)/1024/1024,1) AS size_mb FROM information_schema.tables WHERE table_schema='librenms' GROUP BY table_schema;"

Если MySQL стоит на том же сервере, что и веб/поллер — на инсталляциях от 100 устройств стоит рассмотреть отдельный сервер под СУБД: это снимает конкуренцию за память и диск между базой и RRDtool/InfluxDB, и заодно упрощает бэкапы. Похожая логика разбора нагрузки на компоненты подробно разобрана в статье про настройку Zabbix на VPS — там та же проблема с СУБД под мониторинг решается почти идентично.

RRDtool или InfluxDB: разное давление на память

По умолчанию LibreNMS хранит временные ряды в RRDtool-файлах — по одному .rrd на каждый график каждого устройства. Это экономит место (фиксированный размер файла независимо от истории), но плохо масштабируется по IOPS: чем больше устройств, тем больше мелких файлов, в которые нужно писать каждые несколько минут. На сетевом или медленном диске это превращается в очередь I/O wait, а не в нехватку RAM напрямую — но система начинает агрессивнее кэшировать эти файлы в page cache, отбирая память у MySQL.

InfluxDB как альтернативное хранилище (поддерживается LibreNMS «из коробки» через config.php) переносит запись метрик в LSM-движок, который лучше держит большой поток мелких записей и меньше зависит от количества отдельных файлов. Цена — сама InfluxDB тоже хочет RAM под свой кэш (обычно от 1 ГБ на старте, растёт с объёмом retention).

Практический ориентир:

• До ~100 устройств — оставляйте RRDtool, разница в ресурсах не оправдывает сложность миграции.
• От ~250 устройств или высокая плотность портов — переходите на InfluxDB, особенно если диск — сетевой (Ceph, NFS) или не NVMe.
• В любом случае держите каталог rrd/ (или данные InfluxDB) на отдельном быстром томе — не на системном разделе, где крутится ОС и логи.

Если сравниваете подходы к хранению временных рядов шире, полезно посмотреть на разбор сколько RAM нужно для Grafana Loki — там та же дилемма «файлы на диске vs специализированное хранилище» решается для логов, логика расчёта переносится почти без изменений.

Poller, дискавери и distributed polling

Опрос устройств в LibreNMS запускается через cron — либо классический poller.php по расписанию, либо более современный poller-wrapper.py/dispatcher, который держит пул воркеров и разбирает очередь устройств равномернее. Каждый активный воркер — это отдельный PHP-процесс с собственным потреблением памяти, и при плохо подобранном poller_group/workers числе они начинают запускаться внахлёст, удваивая пиковую нагрузку.

Проверить, не копятся ли зависшие поллеры:

ps aux | grep poller.php | grep -v grep | wc -l

Если число стабильно растёт от опроса к опросу — интервал слишком короткий для объёма устройств, либо один SNMP-запрос подвисает (частая причина — устройство за VPN с плавающей задержкой). В config.php стоит явно ограничить таймауты:

$config['snmp']['timeout'] = 1;      // секунды на попытку
$config['snmp']['retries'] = 3;
$config['rrd']['step'] = 300;        // синхронно с реальным интервалом cron

На инсталляциях от нескольких сотен устройств LibreNMS поддерживает distributed polling — несколько poller-нод забирают куски общего списка устройств из центральной MySQL, а веб и хранилище метрик остаются на одном «главном» сервере. Это решает проблему RAM иначе: вместо одного сервера на 32 ГБ вы держите центральный сервер под БД/веб (8-16 ГБ) и 2-3 poller-ноды по 2-4 ГБ каждая, которые можно располагать ближе к опрашиваемым сегментам сети — это заодно снижает задержки SNMP через VPN-туннели.

Признаки нехватки памяти и как их ловить

Не гадайте — снимайте показания. Базовый набор команд, которые стоит смотреть в первую неделю после запуска:

free -h                              # общая картина, следите за available, не free
vmstat 5 5                           # si/so — если не нули, сервер уже свопится
mysqladmin status                    # Threads_running, растёт — очередь к БД
htop                                 # какой процесс реально ест CPU/RAM в моменте

Тревожные сигналы, что текущего объёма RAM не хватает:

• si/so в vmstat больше нуля на постоянной основе — сервер активно свопит, это уже деградация, а не запас прочности.
• Время выполнения одного цикла poller (видно в LibreNMS в разделе Polling → Overview) превышает выставленный интервал — опрос не успевает завершиться до следующего запуска.
• MySQL Threads_running регулярно выше числа ядер CPU — запросы копятся в очередь.
• Графики в вебе начали отображаться с задержкой в несколько минут после реального события — типичный симптом, что RRDtool/InfluxDB не успевает записывать.

Если видите один из этих признаков при формально «достаточном» по таблице объёме RAM — сначала проверьте innodb_buffer_pool_size и интервал опроса, и только потом увеличивайте сервер. Часто узкое место не в объёме памяти, а в том, как она распределена между MySQL и остальными сервисами. Общие подходы к диагностике на этом этапе пересекаются с материалом про мониторинг диска на VPS — стоит сразу настроить алерт по свободному месту и I/O, чтобы не ловить проблему постфактум.

Частые вопросы