Производительность

Тюнинг хоста, ядра, io_uring и распределение камер по нодам.

Нода рассчитана на тысячи потоков и не перекодирует видео — она перепаковывает уже сжатые данные. Поэтому «медленно» почти никогда не означает нехватку процессора: чаще виноваты параметры ядра, ограничения systemd, диски или сеть. Разбирайте в том порядке, в котором идут разделы ниже.

Сколько ресурсов заложить изначально — Требования и подбор оборудования.

io_uring — основа ввода-вывода#

Нода использует io_uring и для сети, и для файловых операций. Без него она работать не будет.

uname -r                                  # ядро 5.1 и выше
sysctl kernel.io_uring_disabled           # должно быть 0

Установщик кладёт kernel.io_uring_disabled = 0 в /etc/sysctl.d/99-hastreamer.conf. Если политика безопасности дистрибутива переопределяет это значение позже (файл с большим номером), уберите переопределение — иначе после перезагрузки нода встанет.

В журнале ноды при старте видно, удалось ли применить тюнинг:

sudo journalctl -u hastreamer-cctv-node -b | grep -i 'tune:'
# tune: applied … — параметры применены
# tune: ⚠ host is not optimally tuned … — далее перечислены команды, которые нужно выполнить

Рабочие ядра#

Параметр cores в node.conf определяет, сколько ядер обслуживают медиа.

Менять удобнее из админки: Ноды → нода → Сеть и TLS → Рабочие ядра. Значение применяется при следующем перезапуске ноды, а не сразу.

Оставьте хосту запас: если на сервере, кроме ноды, работает Plane, база или что-то ещё, задайте cores меньше, чем всего ядер, — тогда системные задачи не будут конкурировать с обработкой медиа.

Параметры ядра#

Установщик ноды кладёт /etc/sysctl.d/99-hastreamer.conf и применяет его. Ключевые параметры:

# применить после правки
sudo sysctl --system

# проверить фактические значения
sysctl net.ipv4.ip_local_port_range net.core.somaxconn net.core.rmem_max vm.swappiness

Дополнительно нода при старте под root переводит регулятор частоты процессора в режим performance — без него частота «плавает» и появляются рывки на всплесках нагрузки.

Ограничения systemd#

Юнит ноды поставляется с ограничениями, рассчитанными на среднюю установку:

sudo systemctl edit hastreamer-cctv-node

[Service]
MemoryHigh=24G
MemoryMax=32G

sudo systemctl daemon-reload
sudo systemctl restart hastreamer-cctv-node
systemctl show hastreamer-cctv-node -p MemoryMax -p MemoryHigh

Тот же приём применим к Plane (MemoryHigh=1G / MemoryMax=2G по умолчанию) — их стоит поднять на установках с большим числом событий и вложений.

Диски под архив#

Признаки, что диск не справляется: рост задержки записи, рывки при просмотре архива, растущая очередь ввода-вывода. Проверить:

df -h /mnt/dvr                    # заполнение
iostat -x 5 3                     # %util около 100 — диск загружен полностью
du -sh /mnt/dvr                    # реальный объём записей

Хранилища добавляются и настраиваются только из Plane — см. Хранилища DVR. Сетевые файловые системы под архив использовать не стоит: запись идёт непрерывно и чувствительна к задержкам.

Сеть#

• Транспорт до камер — по умолчанию source_transport tcp. Это надёжный вариант, при котором параметры UDP-приёма вообще не используются. Переводите камеры на UDP только при явной необходимости и с пониманием последствий.
• rtp_max_payload 1200 — безопасный размер полезной нагрузки RTP: проходит через VPN-туннели без фрагментации. В однородной локальной сети с MTU 1500 значение можно поднять примерно до 1460.
• Раздельные интерфейсы — на крупных установках развести трафик камер и трафик зрителей по разным сетевым интерфейсам, чтобы всплеск зрителей не влиял на приём.
• Загрузка канала — планируйте не более 50–60 % от номинала интерфейса.

Если камеры забираются по UDP и в метриках растут потери, увеличивайте по одному параметру за раз: udp_ingest_pool_slots, затем udp_ingest_rcvbuf, затем udp_ingest_shards. Все они применяются только после перезапуска — описание в node.conf.

Как понять, что нода перегружена#

Метрики и способы их сбора — Мониторинг и метрики.

Распределение камер по нодам#

Ноды масштабируются горизонтально: две ноды по 250 камер всегда предпочтительнее одной на 500.

Камера привязывается к ноде в её настройках (Камеры → камера → Размещение), там же доступен подбор ноды по текущей загрузке — см. Настройка камер.

Чего делать не нужно#

• Не отключайте io_uring «для безопасности» — нода без него не работает.
• Не ставьте архив на корневой раздел — переполнение остановит и систему, и запись.
• Не выставляйте cores 1 в надежде «ограничить нагрузку»: это создаёт узкое место.
• Не рассчитывайте нагрузку по разрешению камер — значение имеет только битрейт.
• Не правьте управляемую Plane часть node.conf — она будет восстановлена при следующем применении конфигурации. Правьте только верхнюю, системную часть файла.