avreg-gst-rtsp-proxy съел весь CPU

[flot sky]

Испытываю явную нехватку CPU, при этом его "нестабильно" съедают именно avreg-gst-rtsp-proxy процессы.

Выглядит примерно так:

* При запуске avreg сервера (не всегда) на некоторое время 100% CPU съедают avreg-gst-rtsp-proxy процессы.

** Наблюдается даже если клиентов просмотра нет. Выполнял остановку apache2 для гарантии этого

** Иногда и без перезапуска сервиса avreg-gst-rtsp-proxy процессы также резко по непонятной причине занимают весь CPU и спустя время (если сервис не повесится от этого) также "успокаиваются"

** Нагрузка явно снижается при выключении большей части камер

* При запуске хотябы одного из процессов guard-mon avreg-gst-rtsp-proxy процессы на сервере в течении ~2 минут съедают большую часть CPU.

** наблюдается не каждый раз, после остановки guard-mon avreg-gst-rtsp-proxy процессы иногда остаются висеть и потреблять CPU

** К примеру без guard-mon и клиентов просмотра LA ~28, с ним улетает в >100

** отключение большей части камер меняет картину на LA 3-5 в простое, 8-20 при запущенном guard-mon

Дополнительно заметил, что при запуске guard-mon активны avreg-gst-rtsp-proxy процессы явно не связанные с камерами, которые запрашивает avreg-mon, а более клиентов и не должно быть.

Прошу помочь с расследованием. Полагаю, что где-то ошибка в настройке или это какая-то магия декодирования по непонятной мне причине

О конфигурации:

* VM debian12 35 CPU (можем добавить до 40) 25GRAM

* 132 камеры настроенные http://avreg.net/manual_applications_multi-stream.html вариантом частичное декодирование.

* выполнена настройка для avreg-mon v7

* существует на отдельном ПК avreg-mon v7 клиент запущенный в виде 3 отдельных avreg-mon процессов (по одному на монитор)

* подключены профили по 10 avreg камер на профиль

* примерно для половины камер точечно установлен параметр "gstprox_rtspsrc_opts = protocols=tcp latency=500 tcp-timeout=7000000"

Настройки камер (из SQL)

Для камеры по умолчанию задано

InetCam_PASSWD       | ****      
InetCam_USER         | ****
allow_local          | 1
allow_networks       | 1
allow_pda            | 1
decode_video         | 0 # ранее было "декодировать каждый 5 кадр", картину не меняет
events2pipe          | NULL
gstprox_rtspsrc_opts | NULL
motion_detector      | 1
rec_mode             | 1
rtsp_flags           | prefer_tcp
text2img             | 0
use_rtsp_proxy       | gstreamer  
video_src            | rtsp

Остальные камеры подключены в по шаблону

Основной поток

InetCam_IP        | {ip}
InetCam_PASSWD    | NULL
InetCam_USER      | NULL
InetCam_rtsp_port | 554
geometry          | 1280x720 # большая часть камер с 2k(2560x1440) разрешением
motion_detector   | 0
rtsp_play         | RVi/1/1
text2img          | NULL
text_left         | {name}
work              | 1
Дополнительный поток
InetCam_IP        | {ip}          
decode_video      | 1
geometry          | 704x576
mask_file         | /var/lib/avreg/masks/rvi_ipc74.pgm
rec_mode          | 0
rec_target        | {номер камеры с основным потоком}
rtsp_play         | /RVi/1/2
text_left         | {name}_2
work              | 1

[Andrey Nikitin]

flot sky писал(а):

> Дополнительно заметил, что при запуске guard-mon активны
> avreg-gst-rtsp-proxy процессы явно не связанные с камерами, которые
> запрашивает avreg-mon, а более клиентов и не должно быть.

основной клиент avreg-gst-rtsp-proxy - avregd,
иными словами avreg-gst-rtsp-proxy всегда работает

> Прошу помочь с расследованием. Полагаю, что где-то ошибка в настройке или
> это какая-то магия декодирования по непонятной мне причине

разбираться нужно, логи (/var/log/avreg/*), top

[flot sky]

Допускаю, что неправильно оценил источник проблемы. Возможно активно CPU уходит при срабатывании детектора движения и записи камер. Не уверен как точно проверить. Думаю так из-за "Иногда и без перезапуска сервиса avreg-gst-rtsp-proxy процессы также резко по непонятной причине занимают весь CPU".

Дополнительно точечно прошёлся по настройкам камер. От камер отдаётся h264 или h264h, некоторые камеры с аудио.

+ с момента сообщения я выключил половину камер и сместил расположение камер по профилям чтобы 2 потока одной камеры всегда попадали в один профиль.

Теперь и guarg-mon запустить удалось и LA лишь кратковременно подскакивает до ~50, но оставшиеся камеры надо как-то включить.

четверг, 14 августа 2025 г. в 13:29:50 UTC+3, Andrey Nikitin:

[flot sky]

> разбираться нужно, логи (/var/log/avreg/*), top

Не уверен что можно по top увидеть, приложил 2 фото. Первое при "скачке нагрузки", второе после, с ожидаемым CPU потреблением.

+ avreg логи. Бегло своими глазами в них ничего явно проблемного не вижу. Множественные ошибки подключения и задержки списываю на нехватку CPU когда были включены все камеры.

На данный момент профили именуются по шаблону cXX2-XX1 т.к. камеры у меня начинаются со второй, чуть ранее было cXX1-XX0.

четверг, 14 августа 2025 г. в 14:03:17 UTC+3, flot sky:

[flot sky]

> Возможно активно CPU уходит при срабатывании детектора движения и записи камер. Не уверен как точно проверить.

Вроде бы нет. Включил постоянную запись для основных потоков камер и в течении 10 минут особой разницы в нагрузке не увидел

четверг, 14 августа 2025 г. в 14:08:16 UTC+3, flot sky:

[Andrey Nikitin]

flot sky писал(а):

> Дополнительно точечно прошёлся по настройкам камер. От камер отдаётся h264
> или h264h, некоторые камеры с аудио.

а что за h264h?

[flot sky]

> а что за h264h?

Не смог явно найти что это. Описания в интерфейсе камеры нет.

В настройках камер на выбор h264, h264h, h264b, h265.
Большая часть камер умеет только h264h или только h264. Для некоторых получится поменять h264h на h264

Модели камер DH-IPC-HFW2231TP-VFS, RVi-1NCD5069(2.7-13.5), RVi-1NCTL4156 (2.8), RVi-1NCTL4156(2.8), RVi-IPC31VB, RVi-IPC32VL(2.7-12mm), RVi-IPC33VB, RVi-IPC34M (2.8), RVi-IPC42LS (2.8-12), RVi-IPC42S V.2, RVi-IPC42Z5 (7-35), RVi-IPC74

четверг, 14 августа 2025 г. в 14:33:05 UTC+3, Andrey Nikitin:

[Andrey Nikitin]

flot sky писал(а):

> > а что за h264h?
> Не смог явно найти что это. Описания в интерфейсе камеры нет.
> В настройках камер на выбор h264, h264h, h264b, h265.
> Большая часть камер умеет только h264h или только h264. Для некоторых
> получится поменять h264h на h264

Имеет смысл заменить на h264/h265.
Был какой-то h264+ с GOV интервалом в несколько минут, но это полный зашквар, писал уже про это.
Просто не используйте его никогда.

И, кстати, если опять проксики опять за 100% вылезут, посмотрите что со swap-ом, не начал использоваться ли он?

[flot sky]

> И, кстати, если опять проксики опять за 100% вылезут, посмотрите что со swap-ом, не начал использоваться ли он?

Нет, памяти всегда с запасом. На фото top выше ~200Mb в swap так понимаю это системные процессы были вытеснены, более этих значений не наблюдал.

> VM debian12 35 CPU (можем добавить до 40) 25GRAM

Для теста остановил VM, уменьшил количество CPU до 32 и сделал cpuset чтобы VM работала только на "реальных" ядрах гипервизора. (технически я отключил hyper-treading)

И с виду стало сильно лучше. Для половины камер LA немного прыгало, но держалось на ~8.
Включил все камеры. И уже минут 15 наблюдаю LA 28-35 и кратковременные скачки до 50. Но уже не >100 с почти полным зависанием.

Увы это все доступные физические ядра и с виду всё ещё не хватает. Может будут идеи что ещё можно улучшить.

> Имеет смысл заменить на h264/h265.

Пройдусь по камерам, поменяю где получится...

четверг, 14 августа 2025 г. в 15:22:53 UTC+3, Andrey Nikitin:

[flot sky]

> И с виду стало сильно лучше. Для половины камер LA немного прыгало, но держалось на ~8.
> Включил все камеры. И уже минут 15 наблюдаю LA 28-35 и кратковременные скачки до 50. Но уже не >100 с почти полным зависанием.

> Увы это все доступные физические ядра и с виду всё ещё не хватает. Может будут идеи что ещё можно улучшить.

Поспешил с выводами, в течении пары часов стало и до >100 LA прыгать. Странно, в начале дня прыгает до больших значений

>> Имеет смысл заменить на h264/h265.

>Пройдусь по камерам, поменяю где получится...

Прошёлся по примерно половине камер, явно задал или h264 или h265 с фиксированным битрейтом и выключенными "умными кодеками".

Ожидал уже для половины камер увидеть какую-то разницу, но увы картина нагрузки не меняется

Думаю уменьшать количество камер пока проблема не перестанет быть видна и тогда с максимальным логированием посмотреть что происходит, вдруг больше всего видно будет...

четверг, 14 августа 2025 г. в 15:39:51 UTC+3, flot sky:

[Andrey Nikitin]

flot sky писал(а):

> Поспешил с выводами, в течении пары часов стало и до >100 LA прыгать.

Явно что-то ломается.
rtsp-proxy (на gstreamer) не декодирует потоки, он занимается только вводом-выводом, соотв. он не должен жрать процессор.
Похоже что-то ломается.
И тут нужно включать отладку и смотреть логи, а также версии ключевых пакетов (*gstreamer*).

[flot sky]

> Думаю уменьшать количество камер пока проблема не перестанет быть видна и тогда с максимальным логированием посмотреть что происходит, вдруг больше всего видно будет...

Вот что я заметил.

Оказывается некоторые камеры у меня хоть и "в локальной сети", но ping до них >100ms, потерь нет.

Соотв если включать только камеры с "хорошим ping", то и явных скачков CPU не наблюдается. (успешно включил до 30 камер и всё прекрасно работало)

Но стоит включить камеру с "плохим ping" как ошибок нет, а avreg-gst-rtsp-proxy соответствующий профилю начинает иногда "есть CPU как не в себя".

+ некоторые камеры пока к ним avreg не стучится пингуются хорошо, а стоит их "включить" их ping подскакивает до >100ms и приехали.

Выглядит как явная сетевая проблема. 

Я много где указывал gstprox_rtspsrc_opts="protocols=tcp latency=500 tcp-timeout=7000000", может latency и tcp-timeout вносят свою часть в проблему, есть смысл пытаться править значения параметров пока я явно с сетью не разберусь?

пятница, 15 августа 2025 г. в 11:33:09 UTC+3, Andrey Nikitin:

[Andrey Nikitin]

flot sky писал(а):

> Я много где указывал gstprox_rtspsrc_opts="protocols=tcp latency=500
> tcp-timeout=7000000", может latency и tcp-timeout вносят свою часть в
> проблему, есть смысл пытаться править значения параметров пока я явно с
> сетью не разберусь?

для дальних камер можно попробовать
drop-on-latency=true latency=1500