Теперь самое время дать ответы на вопросы, поставленные нами в начале статьи: "Много это или мало? Хорошо или плохо? " Для одного ядра мы считаем приемлемыми следующие значения:
LA 1 - может превышать 1.00, свидетельствуя о кратковременной пиковой нагрузке на систему.
LA 5 - не должен превышать 1.00, в противном случае налицо явный недостаток вычислительных ресурсов.
LA 15 - максимальное значение 0.7 - 0.8, но в любом случае не выше 1.0, в противном случае вы можете получить в три часа ночи звонок от руководства с вопросом: " А что это с нашим сервером???"
ИМХО правильнее оценивать по idle-загрузке в top. 100 - idle даст загрузку в % в реальный момент. У меня LA тоже меньше 2х никогда не опускается, хотя в idle 30-40%, т.е. загрузка около 60-70%
посмотрел частоту, ничего особо не увидел
на нагруженных прыгает в основном, в пределах - 396-792, на пустом в основном - 198-396
количественно оценить на глаз сложно
постоянно в топе по загрузке процессора (на 1-3 месте) процесс - wb-rules
на всех контроллерах, я еще никаких правил не писал, конфигурация правил стандартная - “из коробки”
может там чего-нибудь поправить можно?
смотрел частоту на пустом контроллере, запустил watch с частотой обновления - 0,2 сек, это дало вот такой скачок на графике cpu.util
на загруженных контроллерах, этот график постоянно в районе 50%, там таких скачков при запуске watch нет, только горка небольшая в 5%
зафиксировал частоту CPU на максимуме, на одном из загруженных контроллеров, загрузка CPU упала на 20% примерно, температура не растет
нагрузка на дисковую подсистему не изменилась
обновил сегодня рабочий контроллер, резко подскочила нагрузка процессора, вот характерная картина нагрузки, верхний экран - обновленный контроллер, нижний - не обновленный
загруз до обновления у них был примерно одинаковый
вот график CPU utilization заббикса, три графика
зеленый - обновленный контроллер, до и после обновления
красный - нагруженный контроллер, без обновлений последних
синий - пустой контроллер
и в обновленном контроллере частота уперлась в максимум и не меняется, без всяких доп настроек (при значении по умолчанию в scaling_governor - ondemand)
так же стал выскакивать чаще тригер “mmcblk0: Disk read/write request responses are too high”
и у меня все параметры со счетчиков сразу стали “рваными”, трудно читаемыми
никаких изменений, кроме обновления, не было
нагрузка на контроллер по количеству запусков в сек mqtt.value (в качестве параметра в заббикс агенте), такая:
с частотой запуска 10 сек - 2 параметра
30 сек - 41 параметр
2 мин - 4 параметра
5 мин - 14 параметров
30 мин - 6 пар.
1 час - 1 пар.
2 ч - 6 пар
6 ч -6 пар
итого около 1,7 запуска mqtt.value в секунду, до обновления справлялся на отлично
пункт 3 выполнил, обновление поставил, после этого обновления версии такие:
wb-mqtt-serial/stretch,stretch,now 2.11.0~feature+less-logs+17+d3de92e armhf [установлен]
Wiren Board Smart Home MQTT serial protocol driver.
wb-mqtt-serial-dbgsym/stretch,stretch 1.41.1 armhf
Debug symbols for wb-mqtt-serial
обратил внимание на ошибки в статусе сервиса:
апр 16 09:43:58 wirenboard-AIZ2ODPK wb-mqtt-serial[17036]: WARNING: [modbus] failed to read 2 input(s) @ 4248 of device modbus:38: Serial protocol error: request timed out
апр 16 09:44:38 wirenboard-AIZ2ODPK wb-mqtt-serial[17036]: WARNING: [modbus] failed to read 2 input(s) @ 4248 of device modbus:60: Serial protocol error: request timed out
апр 16 09:47:09 wirenboard-AIZ2ODPK wb-mqtt-serial[17036]: WARNING: [modbus] failed to read 1 input(s) @ 2 of device modbus:43: Serial protocol error: request timed out
апр 16 09:50:15 wirenboard-AIZ2ODPK wb-mqtt-serial[17036]: WARNING: [modbus] failed to read 2 input(s) @ 4248 of device modbus:50: Serial protocol error: request timed out
апр 16 09:53:30 wirenboard-AIZ2ODPK wb-mqtt-serial[17036]: WARNING: [modbus] failed to read 2 input(s) @ 4248 of device modbus:53: Serial protocol error: request timed out
апр 16 09:54:24 wirenboard-AIZ2ODPK wb-mqtt-serial[17036]: WARNING: [modbus] failed to read 2 input(s) @ 4248 of device modbus:38: Serial protocol error: request timed out
апр 16 10:02:15 wirenboard-AIZ2ODPK wb-mqtt-serial[17036]: WARNING: [modbus] failed to read 2 input(s) @ 4248 of device modbus:53: Serial protocol error: request timed out
апр 16 10:03:07 wirenboard-AIZ2ODPK wb-mqtt-serial[17036]: WARNING: [modbus] failed to read 2 input(s) @ 270 of device modbus:43: Serial protocol error: request timed out
апр 16 10:05:51 wirenboard-AIZ2ODPK wb-mqtt-serial[17036]: WARNING: [modbus] failed to read 1 input(s) @ 2 of device modbus:43: Serial protocol error: request timed out
апр 16 10:05:51 wirenboard-AIZ2ODPK wb-mqtt-serial[17036]: WARNING: [modbus] failed to read 4 input(s) @ 4 of device modbus:43: Serial protocol error: request timed out
на контроллере с версией:
wb-mqtt-serial/stretch,now 1.61.0 armhf [установлен]
Wiren Board Smart Home MQTT serial protocol driver.
никаких ошибок в статусе нет, хотя к нему тоже подключены два MAP12 и еще кое что
и загруз процессора тоже меньше (50%)
с “рваными” графиками разобрался, внимательно посмотрев увидел что проблема была и раньше, причем встречалась на нескольких параметров из множества (считываемых одним путем и с одним интервалом), но случалось это очень редко
обновление просто резко усугубило проблему
проблема действительна отображалась в лога заббикс сервера
1094:20210404:032554.581 Zabbix agent item “mqtt.value[/devices/wb-map12h_{$SLAVE_ID2}/controls/Ch 1 Total AP energy]” on host “wb1.ru” failed: first network error, wait for 15 seconds
1112:20210404:032610.675 resuming Zabbix agent checks on host “wb1.ru”: connection restored
но только сейчас, посмотрев по вашему совету частоту сообщений в топиках, до меня дошло, что причина в настройке таймаута на заббикс сервере
после его увеличения этих ошибок не стало
после обновления загрузка процессора еще больше подпрыгнула
при этом красный график - контроллер с wb-mqtt-serial 1.61.0 и с аналогичной загрузкой (таким же почти подключенным количеством оборудования), и если я его обновлю, будет точно такой же скачок нагрузки на процессор
к данному контроллеру подключено:
через боковой интерфейс: WBIO-DI-WD-14 - 1 шт
по каналу RS-485-1:
MAP-12 - 3 шт
MAP-3 - 1 шт
по каналу RS-485-2:
MAP3-H - 1 шт
MS2 v2 - 1 шт
возникла необходимость заменить MAP3-H на MAP12
CPU контроллера в данный момент загружен под 100% практически постоянно
прошу смоделировать ситуацию (подключить к контроллеру такие же модули в таком же количестве)
и сказать что делать?
либо выставить какие-нибудь интервалы (или еще что-то предпринять) для разгрузки процессора
либо сказать, что такая ситуация нормальна - можно смело ставить еще один MAP-12
В вашем текущем конфиге время полного опроса всех регистров MAP больше, чем poll_interval. В результате wb-mqtt-serial непрерывно опрашивает счётчики. При таком режиме опроса число счётчиков на шине не имеет значения, нагрузка на cpu будет всегда одинаковая. Об этом уже писали выше.
Для снижения нагрузки можно сделать следующее:
Решить, какие параметры MAP нужны и сделать шаблон, в котором будут только эти параметры.
Существенно увеличить poll_interval для MAP. Вообще решить с какой частотой надо получать с MAP значения.
Лично от себя совет - откатиться на версию wb-mqtt-serial 1.61.0. Плюс кастомные шаблоны для счетчиков.
Аналогичная тема по нагрузке CPU после обновления, которую я создавал, окончилась ничем. Производитель считает это нормально.
В общем, пришлось исследовать вопрос и заниматься оптимизацией самостоятельно - в итоге, загрузка CPU в среднем около 50%, а LA в районе 1.0-1,3 - это при 12 устройствах на 4 шинах RS-485 плюс еще периодически ресурсоемкие скрипты на python работают.
В вашем конфиге много устройств с редко изменяющимися показаниями. Тестовая версия wb-mqtt-serial, про которую я писал выше должна снизить нагрузку на cpu, т.к. мы улучшили работу с подобными устройствами.
