Добрый день!
После обновления на 2204 load_average вырос с 0,8 до 4 (!). Раньше я добивался снижения нагрузки за счет ограничения частоты опроса различных устройств и их каналов параметрами poll_interval и read_rate_limit_ms. Сейчас оба параметра неактуальны, а логика параметра read_period_ms, как я понял, заключается в установке целевого минимального периода опроса (то есть, не реже, чем 100, 200 или custom мс).
Чем сейчас установить параметры опроса “не чаще, чем”?
Какова логика установки “in queue order”? Можно ли как-то эту очередь регулировать?
У меня пять каналов RS-485 на 115200b по 15 модулей на канале в среднем, и если их опрашивать по принципу “best effort”, то никакого процессора WB не хватит. Кроме того, это приводит к повышенным энергопотреблению и тепловыделению, что отрицательно сказывается на UE и надежности.
Можете прислать свой конфиг? poll_interval и read_rate_limit_ms объявлены устаревшими, но они всё ещё работают.
“Не чаще чем” сейчас надо устанавливать через период опроса.
“in queue order” - это опрос в свободное время, если никаких других регистров не опрашивается.
В конфиге уже этих параметров нет. Раньше было для каждого устройства poll_interval 100, и для некоторых параметров, например для температуры MCU, были выставлены read_rate_limit_ms в 1000. Сейчас же если везде прописать период опроса в 100 и выборочно в 1000 (то есть, опрашивать не реже чем в 100 или 1000 мсм), то в UI постоянно выскакивают восклицательные знаки, так как эти тайминги он не может выдерживать из-за большого количества устройств и параметров. А мне нужно “опрашивать не чаще, чем 100 и 1000”.
poll_interval и read_rate_limit_ms объявлены устаревшими, но они всё ещё работают.
Это означает, что использовать их нельзя, так как рано или поздно они перестанут работать. Кроме того, poll_interval в UI не появляется. read_rate_limit_ms есть, но очевидно не работает, судя по взлетевшему в облака load_average.
poll_interval = 100 при 15 модулях на шине абсолютно эквивалентно текущему in_queue_order. Просто из-за того что пропускной способности шины не хватает для опроса всех 15, и по факту на предыдущем релизе был непрерывный опрос всех модулей по кругу.
Сейчас мы честно показываем, что сервис не может выдержать эти 100мс, раньше мы просто молча опрашивали реже.
Так что в общем при ваших настройках read_rate_limit_ms и poll_interval тоже “не работали”.
При равном по факту опросе устройств нагрузка на процессор выросла. Всё таки не могли бы вы прислать конфиг, чтобы воспроизвести это у нас, и понять, что вызвало повышение нагрузки.
Драма в том, что конфиг старый я не сохранил перед обновлением и изменением параметров в UI, так как сборка еще у меня на столе, а не на живой системе. Не ожидал от разработчиков такой подставы. На будущее буду умнее.
Чтобы воспроизвести нагрузку CPU, достаточно подключить к одному порту 15 модулей MR6 с дефолтным конфигом на скорости 115200. Получите сразу стабильные +2,5 в load_average и +5-7 градусов температуры CPU. И нет ни одного способа нагрузку уменьшить, судя по вашему ответу.
Единственное решение - не использовать такое количество модулей на 2204, или откатиться на 2201? Правильно я понимаю?
Пока, видимо, на 2204 можно отключить опрос ненужных каналов, а для остальных выставить достаточно большой период опроса, чтобы шина не была нагружена на 100%. Либо да, остаться на 2201, пока мы разбираемся с проблемой.
Для этого мне надо изменить 15*13=195 параметров в конфиге. Методом перебора это займет вечность. Было бы неплохо, если бы устанавливался параметр по умолчанию на уровне порта, который бы наследовали все устройства и каналы в порту. Такое возможно?
У процессора в WB огромный запас по рабочей температуре. Это специальный индустриальный процессор, ему вполне нормально работать на 100% загрузки и 100% частоты в течение 15 лет.
В качестве временного обходного пути, я бы ещё порекомендовал понизить приоритет wb-mqtt-serial через что-то типа
renice -n10 -p `pidof wb-mqtt-serial`
или через systemd (systemctl edit wb-mqtt-serial , добавить строчку Nice=10)
load average и загрузка процессора никуда не денется, но других побочных эффектов кроме нагрева (который безвреден, см. выше) не останется.
Спасибо. После ряда экспериментов я довел загрузку до 1,3 путем удаления всех параметров опроса. Любой из них (poll_interval, read_rate_limit_ms) в моей конфигурации приводил лишь к дополнительной нагрузке на CPU и увеличивал задержки обработки событий. Видимо поэтому сразу после обновления со старым конфигом загрузка вырастала до 4-х.
Ещё наблюдение: если отключить часть устройств (см мой конфиг, скриншоты сделаны после отключения всех MDM3 и MRGBW-D параметром Enable device) - то загрузка процессора растет. До отключения было около 2,5, сейчас стабильно 5. Также нагрузка растет, если выключить опрос неиспользуемых каналов (см мой конфиг). С таким же конфигом, но с опросом всех каналов загрузка около 1,5.
Оптимизировали опрос устройств.
К сожалению, полностью воспроизвести нагрузку не вышло, но на “16 MR6C на одном порту” с доработками нагрузка на процессор от wb-mqtt-serial уменьшилась где-то в 2 раза.
Проверьте, пожалуйста, на ваших инсталляциях. Чем больше портов используется, тем заметнее должен быть эффект.
Судя по htop, публикуется много сообщений в MQTT. Это видно по нагрузке на брокер и wb-mqtt-db. Поставьте новую версию wb-mqtt-serial из моего сообщения выше, но, думаю, надо будет разбираться дальше с числом сообщений в MQTT.
На первом скрине опрашивали 2 порта, на втором - 4.
На первом скрине было много публикаций в MQTT (mosquitto и wb-mqtt-db создавали существенную нагрузку), на втором, видимо, меньше.
Нагрузка от wb-rules разная. Возможно, тоже с числом сообщений в MQTT связано.
Я сразу написал, что был оптимизирован именно опрос, и в ситуации с первого скрина эффект будет ограниченный.
По хорошему надо иметь статистику по нагрузке от сетапа до обновления и после. Без изменения настроек. Тогда можно сравнивать и искать проблемные места.
