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

MAATRIX

NetBox редко падает от количества устройств в базе — он падает от числа процессов, которые сам же и плодит. Каждый gunicorn-воркер — это отдельная копия Django со всеми загруженными моделями и плагинами, и формула «2×ядра+1» на четырёхъядерной машине даёт девять таких копий. Добавьте PostgreSQL, Redis, RQ-воркер для фоновых задач и housekeeping — и двух гигабайт, которые интуитивно кажутся достаточными для «просто базы IP-адресов», не хватит уже на старте. Считаем по компонентам и с реальными командами для проверки.

Короткий ответ: сколько RAM нужно для NetBox

Ориентир для сервера, где NetBox — единственный сервис.

Главное: NetBox — это не один процесс, а связка из пяти-шести, и умножение воркеров gunicorn на число ядер обычно съедает памяти больше, чем рост самой базы данных. Дефолты рассчитаны на «нормальный» сервер, а не на бюджетный VPS — их придётся подрезать вручную, и об этом ниже.

Куда уходит память: приложение, PostgreSQL и Redis

NetBox — это Django-приложение, которое обслуживает WSGI-сервер (в официальном docker-compose — gunicorn). Каждый воркер gunicorn — полноценный процесс Python с загруженным Django и всеми включёнными плагинами. Базовый воркер без нагрузки держит ориентировочно 150–250 МБ RSS, и это не мелочь — шаблон gunicorn_config.py по умолчанию считает число воркеров по классической формуле gunicorn (2 × ядра) + 1. На 2 vCPU это пять процессов, уже под гигабайт только на прикладной слой.

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

docker compose exec netbox ps aux | grep gunicorn
docker stats --no-stream netbox netbox-worker netbox-postgres netbox-redis netbox-redis-cache

Дальше — база. NetBox не работает без PostgreSQL, SQLite не поддерживается вовсе. Postgres в покое держит shared_buffers (по умолчанию 128 МБ, если не переопределяли) плюс по 5–10 МБ на каждое активное соединение:

docker compose exec postgres psql -U netbox -c "SHOW shared_buffers;"
docker compose exec postgres psql -U netbox -c "SELECT count(*) FROM pg_stat_activity;"

При дефолтном max_connections = 100 реально открыто обычно 10–30 соединений — то есть 100–300 МБ, не всё «максимальное» пространство.

Redis фигурирует дважды: один инстанс — очередь задач для RQ, второй — redis-cache под кэш Django. По отдельности каждый в лёгкой нагрузке — десятки мегабайт, но maxmemory для кэша стоит задать явно, иначе Redis по умолчанию не ограничен и будет расти, пока не упрётся в память хоста:

maxmemory 256mb
maxmemory-policy allkeys-lru

Итог по «тихому» состоянию на связке 2 gunicorn-воркера + Postgres + два Redis — около 900 МБ – 1,2 ГБ, прежде чем добавить фоновые задачи и housekeeping.

RQ-воркер и фоновые задачи: вебхуки, скрипты, импорт

Отдельный процесс netbox-worker запускает python manage.py rqworker — это ещё одна полная копия Django-приложения, весом сравнимая с gunicorn-воркером (150–250 МБ в простое). Через неё проходит всё асинхронное: отправка вебхуков при изменении объектов, запуск пользовательских скриптов (Custom Scripts) и отчётов (Reports), массовый импорт через CSV или REST API.

Именно массовые операции — источник кратковременных пиков. Импорт нескольких тысяч устройств одним запросом через API или CSV-загрузку в UI строит объекты в памяти партиями перед сохранением в базу — на инвентаре в 5–10 тысяч строк RQ-воркер может кратковременно занять в разы больше своего обычного объёма. Если импорт падает без внятной ошибки в интерфейсе, первым делом смотрите не логи NetBox, а системный журнал:

dmesg -T | grep -i "killed process"
journalctl -u docker --since "1 hour ago" | grep -i oom

Строка Out of memory: Killed process (python) с именем воркера — это ваш случай: делите импорт на пачки по 500–1000 записей вместо одного файла на несколько тысяч строк.

Отдельно поднят netbox-housekeeping — периодическая задача, которая чистит сессии, обрезает журнал изменений по CHANGELOG_RETENTION (по умолчанию 90 дней) и удаляет старые токены. В покое процесс почти не потребляет память, но на инсталляции с историей в миллионы записей разовая чистка ощутимо грузит и CPU, и Postgres — планируйте её на ночное окно.

Как растёт память вместе с инвентарём

Рост числа устройств, IP-адресов и VLAN сам по себе не увеличивает базовое потребление RAM линейно — это в первую очередь нагрузка на диск и на Postgres (размер таблиц, индексы, время выполнения запросов), а не на память gunicorn-воркеров. Прямое влияние на память дают три вещи:

• Кастомные поля и теги. Каждое дополнительное custom field на модель устройства увеличивает объём JSON, который Django десериализует при каждой выборке. На списке в 500+ строк это заметно на времени ответа, но не критично для памяти самого процесса.
• Плагины. Каждый плагин (netbox-topology-views, netbox-bgp, свои интеграции) регистрируется в Django на старте и увеличивает вес каждого воркера gunicorn — то есть плагины умножаются на число воркеров, а не добавляются один раз.
• NAPALM и живой опрос устройств. Скрипты с NAPALM или netmiko для опроса реального оборудования держат открытое SSH-соединение и буфер вывода в памяти RQ-воркера на каждый сеанс. Опрос полусотни устройств разом — заметный пик, его стоит ограничивать батчами.

GraphQL API (/graphql/) отдельно стоит упомянуть: сложные вложенные запросы по связанным объектам (устройство → интерфейсы → IP-адреса → VRF) строят вложенную структуру в памяти перед сериализацией в JSON. На большом инвентаре и неограниченной глубине это может занять сотни мегабайт на один запрос — ограничивайте глубину на стороне клиента API.

Docker Compose против установки из исходников

Официальный способ — netbox-community/netbox-docker, и это шесть отдельных контейнеров: netbox, netbox-worker, netbox-housekeeping, postgres, redis, redis-cache. У такой схемы накладные расходы выше, чем у установки из исходников на одну машину: каждый контейнер держит собственный набор соединений и не делит кэш файловой системы так эффективно, как процессы на голом хосте. Взамен — изоляция: обновление NetBox не тянет за собой пересборку Postgres.

Установка из исходников (venv + systemd-юниты, отдельно установленные Postgres и Redis) экономит 200–400 МБ за счёт отсутствия контейнерной обвязки, но требует руками следить за зависимостями при апгрейде — процесс описан в руководстве по обновлению. На 2 ГБ RAM выбирайте установку из исходников с ручной настройкой gunicorn_config.py на 2 воркера — контейнерный стек по умолчанию на такой машине стабильно не запустится. На 4 ГБ и выше разница уже не принципиальна.

Как ужать NetBox под свою память

Первое и самое весомое — число воркеров gunicorn. В configuration/gunicorn_config.py (или через переменную окружения, если используете свежий образ netbox-docker с поддержкой GUNICORN_WORKERS) задайте фиксированное число вместо формулы по ядрам:

workers = 2
threads = 2
max_requests = 5000
max_requests_jitter = 500

max_requests с джиттером — защита от постепенного разрастания памяти воркера при долгой работе (типичная утечка в长-живущих Python-процессах через кэши ORM): воркер перезапускается сам, не дожидаясь OOM.

Второе — очередь RQ. По умолчанию поднят один netbox-worker; не увеличивайте число реплик без необходимости, каждая — полная копия Django. Если вебхуки и скрипты у вас редкие, одного воркера достаточно даже на 4 ГБ.

Третье — Postgres. На небольшой машине не оставляйте shared_buffers по умолчанию нетронутым — на выделенном под NetBox сервере разумно поднять его до 25% RAM, но зафиксировать max_connections ниже дефолтных 100, если параллельных клиентов реально 10–20:

shared_buffers = 512MB
max_connections = 40
work_mem = 8MB

Четвёртое — кэш. CACHE_TIMEOUT в configuration.py и maxmemory у redis-cache — не давайте кэшу расти бесконтрольно на маленьком сервере, лучше короче TTL и чаще промахи, чем Redis, съевший половину памяти хоста.

Про своп на такой связке процессов — отдельный разговор, здесь пригодится общий подход из статьи про правильный размер swap для VPS: 1–2 ГБ свопа страхуют от разового пика при импорте, но не заменяют памяти для постоянной работы шести процессов.

Как измерить свои требования и не гадать

Самый честный способ — снять пик по каждому контейнеру за неделю реальной работы, а не полагаться на цифры из статьи:

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}"

Если контейнеры запущены под systemd напрямую (установка из исходников), точный пик за время жизни процесса — в memory.peak cgroup:

cat /sys/fs/cgroup/system.slice/netbox.service/memory.peak

Для Postgres полезно смотреть не память процесса, а размер базы — он подскажет, когда пора увеличивать shared_buffers:

docker compose exec postgres psql -U netbox -d netbox -c "SELECT pg_size_pretty(pg_database_size('netbox'));"

Порядок действий: разверните на 4 ГБ с двумя воркерами gunicorn, снимите пики через неделю обычной работы (включая один плановый импорт устройств), прибавьте 20–30% запаса — это и есть ваша цифра, а не абстрактный минимум из документации. Смежный вопрос эксплуатации — мониторинг самого сервера с NetBox, о нём в статье про установку Zabbix на VPS.

Какой сервер взять в MAATRIX под NetBox

Честный минимум: 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe. Это официальный docker-compose стек из шести контейнеров с двумя-тремя воркерами gunicorn и небольшим инвентарём — до пары тысяч устройств и IP-адресов. Меньше 4 ГБ на полном стеке брать не стоит: связка Postgres + два Redis + минимум два Python-процесса просто не умещается стабильно, разовые всплески на импорте или housekeeping будут регулярно ронять контейнеры по OOM.

Комфортный вариант: 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe. Инвентарь на несколько тысяч устройств, пара плагинов, регулярные скрипты с NAPALM-опросом и вебхуки во внешние системы (тикет-системы, системы мониторинга). Эту конфигурацию советуем как основную для рабочей команды сетевых инженеров.

Для крупного инвентаря: 6–8 vCPU, 16 ГБ RAM, 160 ГБ NVMe. 10 000+ устройств и IP, GraphQL-нагрузка от внешних систем, несколько активных RQ-воркеров под пиковые вебхуки. На таком объёме имеет смысл вынести PostgreSQL на отдельный сервер — тогда прикладной части NetBox достаточно и меньшего тарифа.

Локация — по расположению вашей инфраструктуры. NetBox обычно живёт рядом с остальным мониторингом — если он в России, держите NetBox там же по задержке до Zabbix и NAPALM-опроса; для распределённой по Европе сети подойдёт Лондон или Франция.

NetBox из каталога apps.maatrix.io разворачивается на сервер автоматически при заказе, включая базовый docker-compose стек — начальные логин и адрес появляются в личном кабинете, в разделе «Доступ», дальше вы уже правите configuration.py и число воркеров под свои цифры. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT.

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