Существенное увеличение нагрузки после обновления до последних версий, в частности wb-mqtt-serial

В продолжение Как можно оптимизировать wb-mqtt-db? - #3 от пользователя oddentity

В среде админов есть примета - “работает - не трогай”. Но решил обновить все ПО до последних версий на свою голову. Из изменений заметил только существенно увеличение нагрузки и без того слабенького CPU.

Как видно, нагрузка не опускается ниже 65-70%, иногда до 80%. До обновления было 40-45, редко 55%.
Больше всего смущает увеличение нагрузки более чем в 2 раза процесса wb-mqtt-serial - с тем же самым конфигом было 7-10%, а стало 22-23%. Почему так и что с этим делать? Это же ненормально, когда с 12 устройствами такая нагрузка. Более того, большинство шаблонов переписаны, и из них убрано около половины стандартных топиков (опрашиваются только нужные).
Вот мой конфиг wb-mqtt-serial:

    "debug": false,
    "ports": [
        {
            "path": "/dev/ttyRS485-1",
            "devices": [
                {
                    "slave_id": 75,
                    "device_type": "WB-MR6 (no spaces)",
                    "id": "relay01",
                    "name": "Relay01 WB-MR6LV-S"
                },
                {
                    "slave_id": 45,
                    "device_type": "WB-MR3 (no spaces)",
                    "id": "relay02",
                    "name": "Relay02 WB-MR3LV-S"
                },
                {
                    "slave_id": 37,
                    "device_type": "WB-MR3 (no spaces)",
                    "id": "relay03",
                    "name": "Relay03 WB-MR3LV-I"
                },
                {
                    "slave_id": 159,
                    "device_type": "WB-MDM3 (no spaces)",
                    "id": "dimmer01",
                    "name": "Dimmer01 WB-MDM3"
                },
                {
                    "slave_id": 141,
                    "device_type": "WB-MRGBW-D 4 channels (my)",
                    "id": "dimmer02",
                    "name": "Dimmer02 WB-MRGBW-D"
                }
            ],
            "baud_rate": 115200,
            "parity": "N",
            "data_bits": 8,
            "stop_bits": 2,
            "poll_interval": 10,
            "enabled": true
        },
        {
            "path": "/dev/ttyRS485-2",
            "devices": [
                {
                    "slave_id": "59",
                    "device_type": "WB-MAP12H fw2 (no spaces)",
                    "name": "Energy01 WB-MAP12H",
                    "id": "energy01",
                    "poll_interval": 200
                },
                {
                    "slave_id": "40713747",
                    "device_type": "Mercury 206",
                    "name": "Energy02 Mercury206",
                    "id": "energy02"
                }
            ],
            "baud_rate": 9600,
            "parity": "N",
            "data_bits": 8,
            "stop_bits": 1,
            "poll_interval": 10,
            //"response_timeout_ms": 1000,
            "enabled": true
        },
        {
            "path": "/dev/ttyMOD1",
            "devices": [

                {
                    "slave_id": 28,
                    "device_type": "WB-M1W2",
                    "name": "Temperature01",
                    "id": "temperature01"
                },
                {
                    "slave_id": 89,
                    "device_type": "WB-MSW v.3 (no spaces) hall",
                    "name": "Climate01 WB-MSW v3",
                    "id": "climate01"
                }
            ],
            "baud_rate": 9600,
            "parity": "N",
            "data_bits": 8,
            "stop_bits": 2,
            "poll_interval": 100,
            "enabled": true
        },
        {
            "address": "192.168.43.170",
            "port": 1170,
            "devices": [
                {
                    "slave_id": "51",
                    "device_type": "WB-MR3 (via WB-MGE)",
                    "name": "Relay05 WB-MR3LV/I",
                    "id": "relay05"
                },
                {
                    "slave_id": "91",
                    "device_type": "WB-M1W2 (no spaces)",
                    "name": "Temperature02",
                    "id": "temperature02"
                },
                {
                    "slave_id": "43",
                    "device_type": "WB-MRM2-mini (via WB-MGE)",
                    "name": "Relay04 WB-MRM2-mini",
                    "id": "relay04"
                }
            ],
            "port_type": "tcp",
            "poll_interval": 2000,
            "response_timeout_ms": 5000
        }


    ]
}

Версии установленного ПО:

python-wb-common/stretch,stretch,stretch,stretch,now 1.3.3 all [installed,automatic]
python-wb-io/stretch,now 1.2.3 armhf [installed]
python3-wb-mcu-fw-updater/stretch,stretch,stretch,stretch,now 1.0.7 all [installed,automatic]
u-boot-tools/stretch,stretch,stretch,stretch,now 2:2017.03+wb-2 all [installed]
u-boot-tools-wb/stretch,stretch,now 2:2017.03+wb-2 armhf [installed,automatic]
wb-configs/stretch,stretch,stretch,stretch,now 1.84.3 all [installed]
wb-configs-stretch/stretch,stretch,stretch,stretch,now 1.84.3 all [installed]
wb-daemon-watchdogs/stretch,stretch,now 1.1 all [installed]
wb-dt-overlays/stretch,stretch,stretch,stretch,now 1.3 all [installed]
wb-homa-adc/stretch,stretch,now 2.0.10 armhf [installed]
wb-homa-gpio/stretch,stretch,now 2.1.0 armhf [installed,auto-removable]
wb-homa-rfsniffer/stretch,now 1.0.9 armhf [installed]
wb-homa-w1/stretch,stretch,now 1.10.1 armhf [installed]
wb-hwconf-manager/stretch,stretch,stretch,stretch,now 1.38.3 all [installed]
wb-mcu-fw-flasher/stretch,stretch,now 1.0.7 armhf [installed]
wb-mcu-fw-updater/stretch,stretch,stretch,stretch,now 1.0.7 all [installed]
wb-mqtt-adc/stretch,now 2.0.10 armhf [installed]
wb-mqtt-confed/stretch,stretch,now 1.2.5 armhf [installed]
wb-mqtt-dac/stretch,stretch,stretch,stretch,now 1.1.1 all [installed]
wb-mqtt-db/stretch,now 1.7.3 armhf [installed]
wb-mqtt-db-cli/stretch,stretch,stretch,stretch,now 1.2.1 all [installed]
wb-mqtt-gpio/stretch,stretch,now 2.1.0 armhf [installed]
wb-mqtt-homeui/stretch,stretch,stretch,stretch,now 2.3.3 all [installed]
wb-mqtt-mbgate/stretch,now 1.0.1 armhf [installed]
wb-mqtt-serial/stretch,stretch,now 2.7.1 armhf [installed]
wb-mqtt-snmp/stretch,now 1.0.1 armhf [installed]
wb-rules/stretch,now 2.6.3 armhf [installed]
wb-rules-system/stretch,stretch,stretch,stretch,now 1.6.9 all [installed]
wb-test-suite/stretch,stretch,stretch,stretch,now 1.20 all [installed]
wb-utils/stretch,stretch,now 2.1.5 all [installed,automatic]
wb-zigbee2mqtt/stretch,stretch,stretch,stretch,now 1.0.0 all [installed]

Версия контроллера 6.6.0

dpkg -s wb-hwconf-manager:

Package: wb-hwconf-manager
Status: install ok installed
Priority: extra
Section: misc
Installed-Size: 365
Maintainer: Evgeny Boger boger@contactless.ru
Architecture: all
Version: 1.38.3
Depends: ucf, wb-utils (>= 2.1.2), wb-configs (>= 1.63), perl, jq, tcc, device-tree-compiler (>= 1.6.0-1), linux-image-wb6 (>= 4.9+wb20201021233713) | linux-image-wb2 (>= 4.9+wb20200925234629), mqtt-tools (>= 1.1.1), wb-mqtt-dac (>= 1.1), wb-rules-system (>= 1.6.8)
Breaks: wb-homa-adc (<< 1.14.2), wb-mqtt-confed (<< 1.0.2), wb-mqtt-homeui (<< 1.6.1)
Conffiles:
/etc/init.d/wb-hwconf-manager 5d64ded12deba13b2aa7843f4a6986d0
/etc/wb-configs.d/02wb-hwconf-manager 57b22000bd3e5e02eefaec1705662f8f
Description: Provides infrastructure for hardware re-configuration via Device Tree overlays

Еще одно замечание - логирование. Только я более-менее избавился от мусора в системном логе, как после обновления опять посыпалась тонна ненужного спама в системный лог. Прежние настройки не работают, т.к. насколько я понял теперь перешли на rsyslog, и все что касалось syslog обычного уже не актуально?

В общем, также нужны инструкции как избавиться от мусора в системном логе с новым rsyslog - сейчас туда валится вообще все: от таймаутов wb-mqtt-serial до КАЖДОГО пакета zigbee2mqtt (зачем?).

Добрый день!

Я понимаю ваше негодование, но очень прошу уважать нашу работу и писать немного корректнее.

Пожалуйста сделайте отдельную тему на это.

В этой теме мы постараемся разобраться с увеличившейся нагрузкой на процессор от wb-mqtt-serial.

Так как у вас нестандартные шаблоны, то нам они понадобятся. Прошу собрать их все в архив и приложить здесь ссылку.

Моё первое предположение: в новом wb-mqtt-serial уменьшились таймауты устройств, поэтому они опрашиваются чаще. Больше опросов - больше сообщений - больше нагрузка.

Попробуйте пожалуйста:

  1. Сделать mosquitto_sub -v -t /# | ts , записать в течение пяти минут, результат в виде файла выложить сюда
  2. Откатить wb-mqtt-serial до версии, которая была у вас до этого. Это делается через apt install wb-mqtt-serial=версия. Повторить п. 1.
  3. Поставить снова самый свежий wb-mqtt-serial, но явно поставить poll_interval в 1000. Проверить загрузку CPU

Проверил. Версия wb-mqtt-serial 2.7.1:
Все 4 шины с poll_interval 10 - загрузка CPU 26-27%
Шины RS-485 с poll_interval 10, TCP-шина за WB-MGE с poll_interval 1000 - 22-23%
Все 4 шины с poll_interval 1000 - 13-14%

Версия wb-mqtt-serial 1.61.0:
Все 4 шины с poll_interval 10 - загрузка CPU 8-9%!
Все 4 шины с poll_interval 1000 - 6-7%

Возможно, вас натолкнет на мысли вот что. Если оставить на 2-ой шине только один Меркурий206, а все остальное на всех шинах выключить, то на 2.7.1 получаем весьма странные результаты:
Дефолтный шаблон, poll_interval = 10 - загрузка CPU 5-6% и куча таймаутов в логе.
Мой шаблон с frame_timeout_ms = 100 и poll_interval = 10 - загрузка CPU 2% и чисто в логе!
Как минимум, тут что-то не так.

Еще одна странность. На 2.7.1 в лог постоянно сыплют таймауты с диммеров (WB-MDM3 и WB-MRGB-W) - раз в минуту-две-три. На старой версии с тем же конфигом таймаутов практически нет, изредка раз в 1-2 часа.

Сделал, но не хотелось бы выкладывать в общий доступ, т.к. там видны имена и описание всех устройств в т.ч. виртуальных. Могу прислать куда-нибудь на email.

Шаблоны приложил (поменять расширение на .zip)templates.pdf (5.6 КБ)

можно здесь же отправить мне личное сообщение

  1. Провели экспермент на нашем Меркурии 206RN. Что с frame_timeout_ms=100, что без него ошибок в обмене нет. Разница в нагрузке возникает из-за того, что при frame_timeout_ms=100, сервис перед каждым запросом ждёт 100 мс. В результате запросов в разы меньше и нагрузка меньше. Можете прислать лог обмена с Меркурием с включенной диагностикой?
  2. Можете прислать лог обмена с диммерами, где есть ошибки? Лучше тоже с включенной диагностикой.
  3. Мы сделали тестовый вариант драйвера, который в нормальном режиме пишет меньше сообщений в лог. Также в нём можно посмотреть обмен по какому порту создаёт наибольшую нагрузку. Это удобно сделать через htop в древовидном режиме с включенными именами потоков. Можете прислать скриншот htop, чтобы было понятнее где дальше разбираться? Установить новый драйвер можно так.
echo 'deb http://releases.contactless.ru/experimental.7 stretch main' > /etc/apt/sources.list.d/wb-experimental-7.list
apt update
apt install wb-mqtt-serial=2.11.0~feature+less-logs+17+d3de92e
  1. Версии wb-mqtt-serial 2.x в принципе чаще опрашивают устройства, чем версии 1.x. В 1.x по умолчанию есть задержка 100 мс перед опросом каждого устройства, регулируется через параметр delay_ms у каждого устройства. В 2.x этого параметра и задержки нет.

Как это включить? debug: true в конфиге? Непосредственно для одного устройства дебаг не включается, а глобально создается огромная нагрузка процессом rsyslog и systemd так что все просто виснет.

Вот так было на старой версии 1.61. Как видно, 10 ошибок за 12 часов:

# cat /var/log/messages | grep "modbus:141" | tail -n 10
Apr 13 23:09:07 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 3 input(s) @ 32 of device modbus:141: Serial protocol error: request timed out
Apr 14 00:36:46 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 03:06:23 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 4 holding(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 03:36:29 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 4 coil(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 04:50:56 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 3 input(s) @ 32 of device modbus:141: Serial protocol error: request timed out
Apr 14 06:57:31 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 1 input(s) @ 121 of device modbus:141: Serial protocol error: request timed out
Apr 14 07:36:41 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 4 holding(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 08:33:12 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 3 input(s) @ 32 of device modbus:141: Serial protocol error: request timed out
Apr 14 09:19:44 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 4 coil(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 09:38:20 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 3 input(s) @ 32 of device modbus:141: Serial protocol error: request timed out

А вот так стало после обновления до 2.11.0~feature+less-logs+17+d3de92e:

Apr 14 12:43:21 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: INFO: [serial client] device modbus:141 is connected
Apr 14 12:43:34 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 12:55:51 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:01:11 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:08:28 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:11:07 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:16:47 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:17:17 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 4 coil(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:17:40 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 4 holding(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:19:26 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 4 coil(s) @ 0 of device modbus:141: Serial protocol error: request timed out

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

Сделал. Конфиг MAP12H вернул на дефолтный, т.к. ругается на собственные типы данных и не запускается, на всех шинах poll_interval = 10

А для чего это сделано?
Давайте поставим вопрос иначе: какие параметры надо прописать в шаблоны устройств или в конфиге wb-mqtt-serial, чтобы нагрузка вернулась к прежнему уровню версий 1.х? Ибо 30% нагрузка на 12 устройствах - совершенно неприемлемо. А если будет 20-30 устройств - все вообще повиснет?

странный вопрос. wb-mqtt-serial опрашивает устройства так часто, как позволяет пропусная способность шины, чтобы у вас были наиболее актуальные данные.
Максимальная частота опроса регулируется значением poll_interval. Просто в драйвере 1.x при вашем наборе устройств из-за неоптимальной работы эта настроенная максимальная частота не достигалась.

Поставьте poll_interval для порта в 1000, например: так каждый регистр будет опрашиваться не чаще, чем раз в секунду.

Нет, т.к. опросы сейчас ограничены пропускной способностью RS-485. Если немного упростить, то количество запросов в секунду и нагрузка на CPU не зависят от количества устройств в конфиге.

так нельзя, к сожалению.

виснет - это в смысле вы по ssh не можете подключиться? Или просто медленно работает?
Судя по вашему логу, за 10 минут было несколько ошибок, так что включить это достаточно минут на 10 - нам хватит информации.

Я уже пробовал это в самом начале - и писал раньше:

Т.е. все равно в 2 раза нагрузка выше.
Да и в моих кастомных шаблонах и так многие регистры установлены в poll_interval 1000 или даже 10000, но вот некоторые регистры нужно опрашивать почти мгновенно для соотв. скорости реакции на датчики движения, например, или нажатие клавиш.

Видимо, я не так понял ваш вопрос. Если вопрос был в том, как снизить нагрузку до приемлимого уровня, то ответ - увеличить poll_interval.

Да, wb-mqtt-serial 2.7.1 медленнее, чем старый wb-mqtt-serial 1.61.0. Мы это знаем и планируем когда-нибудь заняться оптимизацией. Приоритет не очень высокий, потому что 15% загрузки процессора - это более чем приемлимая нагрузка.

Если для вас эти 8% разницы по какой-то причине принципиальны, то рекомендую пока использовать старую версию.

В моем случае нагрузка всей системы увеличивается примерно на 30%: около 50% на старой версии, и порядка 75-80% с новой. Насколько это критично? Ну, если бы до обновления было 10%, а стало 40% - да, это не критично. Но когда было 50%, а стало 80% - это уже критично, т.к. практически не остается запаса на выполнение каких-то скриптов или запросов из исторической базы - во время их выполнения CPU упрется в “полку”, а это уже скажется на отзывчивости и быстродействии движка правил.

Такая же ситуация описана и в этой ветке - наглядно, с графиком. У меня все в точности аналогично. Другие скорее всего просто еще не обновлялись.

А в чем тогда преимущество новой версии? Может, надо было сначала оптимизировать, а потом выкладывать обновление? У меня нет возможности заниматься глубоким бета-тестированием и ставить тестовые сборки, снимать дебаги - контроллер постоянно в работе и это доставляет много неудобств. Почему бы вам самим не собрать тестовый стенд с аналогичным наборот устройств? Тем более, есть уже 2 темы.
А пока да, я откатился на старую версию.

  • работа через systemd, удобное логгирование, автоматический перезапуск
  • отсутствие огромных задержек между опросами регистров, шина используется гораздо эффективнее, максимальный период опроса каналов увеличился
  • обработка ошибок записи регистров и setup-значений
  • определение неподдерживаемых устройством регистров: они опрашиваются только первый раз, а больше не опрашиваются
  • поддержка Modbus TCP
  • поддержка протоколов датчиков НЕВА и Энергомера
  • поддержка пользовательских шаблонов
  • поддержка широковещательных адресов для некоторых протоколов
  • улучшена поддержка битовых масок

Новый wb-mqtt-serial вышел в районе сентября, так что это не уже 2 темы, а всего 2 темы за полгода.

Мы долго разрабатывали и в ближайшие недели внедрим разделение на стабильные и тестовые релизы, чтобы тестировать новые версии исключительно на добровольцах. Другое дело, что “новый” wb-mqtt-serial не такой уж и новый, и с ним это вряд ли бы сработало.

Просто большинство не обновляет ПО, если все работает, ничего не глючит и не требуется новый функционал… А те, кто купили контроллер с уже предустановленной новой версией, думают, что так и должно быть.