Существенное увеличение нагрузки после обновления до последних версий, в частности 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 не такой уж и новый, и с ним это вряд ли бы сработало.

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

1 лайк

В силу определенных обстоятельств на одном объекте пришлось возвращать контроллер к заводским настройкам, сейчас процессор грузится до 70%, при старте и все 100% с одной шиной, на которой 4 счетчика WB-MAP12E. Desired poll interval (ms) = 20 (пробывал 1000/10000) без результатно.

Если сделать enable еще 2 шины которые сидят на serial over tcp, на которых еще 4 счетчика WB-MAP12E то процессор грузится до 100%. Для данных шин Desired poll interval (ms) - 1000 (пробывал и 10 сек без результатно.)

root@wirenboard-AN3PDYLU:~# dpkg -s wb-mqtt-serial
Package: wb-mqtt-serial
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 1681
Maintainer: Evgeny Boger <boger@contactless.ru>
Architecture: armhf
Version: 2.7.1
Replaces: wb-homa-modbus (<< 1.14.1)
Depends: libc6 (>= 2.4), libgcc1 (>= 1:3.5), libjsoncpp1 (>= 1.7.4), libstdc++6 (>= 6), libwbmqtt1 (>= 1.1.0), init-system-helpers (>= 1.18~), ucf, bsdutils
Breaks: wb-homa-modbus (<< 1.14.1), wb-mqtt-confed (<< 1.0.2), wb-mqtt-homeui (<< 1.7)
Conffiles:
 /etc/wb-configs.d/11wb-mqtt-serial 25dea7134dcb1cd4ec4e4f33524635e0
 /etc/wb-mqtt-serial.conf.sample c8c1adbf630e6fd7ec871b1b5c4a5e0f
Description: Wiren Board Smart Home MQTT serial protocol driver.

пробывал обновить до 2.7.5 вышли ошибки и пакет не встал.

конфиг - wb-mqtt-serial.conf (32.9 КБ)

Провел эксперимент - оставил только одну шину (остальные удалил) и в единственной шине только 1 счетчик. Загрузка процессораа составила в среднем 18-20%. С двумя уже 70%, причем не важно какой счетчик добавлял 2 или 3.

Ну не могут два устройства так нагибать контроллер!

что порекомендуете?

Попутный вопрос судя по информации последняя стабильная версия wb-mqtt-serial (2.31.0), почему она не устанавливается при обновлении?

Позвольте полюбопытствовать (ибо опасаюсь вляпаться в это сам) - а фактический интервал опроса меняется? Т.е. если в терминале подписаться на нужные топики, значения валятся чаще/реже, или с неизменной скоростью? Помнится, приходилось интервалы подкручивать индивидуально, кое-где демон их игнорил, только сейчас не припомню, где конкретно.

не заметил существенной разницы, при 20 конечно по чаще, при 1000 чуть реже, но не кратно секунде. При 10 000 не раз в 10 секунд, а когда как и через 15 сек может и через 2 секунды.

Короче непонятно

Наблюл примерно похожее. Значит, глючит не меня.

Вот скрин с другого объекта, там тоже wb-mqtt-serial 2.7.1 устройств порядка 15 на всех шинах, но такой загрузки не наблюдаю. На данном объекте нет счетчиков WB-MAP остается только гадать и ждать комментариев и рекомендаций от WB.