Новая логика параметров опроса wb-mqtt-serial в wb-2204

Оптимизировали опрос устройств.
К сожалению, полностью воспроизвести нагрузку не вышло, но на “16 MR6C на одном порту” с доработками нагрузка на процессор от wb-mqtt-serial уменьшилась где-то в 2 раза.
Проверьте, пожалуйста, на ваших инсталляциях. Чем больше портов используется, тем заметнее должен быть эффект.

Установить можно так:

echo "deb http://deb.wirenboard.com/experimental/7 stable main" > /etc/apt/sources.list.d/experim.7.list
apt update
apt install wb-mqtt-serial=2.62.0~exp~bugfix+49364+cpu+load~2~ge81596f

Судя по htop, публикуется много сообщений в MQTT. Это видно по нагрузке на брокер и wb-mqtt-db. Поставьте новую версию wb-mqtt-serial из моего сообщения выше, но, думаю, надо будет разбираться дальше с числом сообщений в MQTT.

Поставил. Сходу кажется, что ничего не изменилось.
Было вот так:

Стало вот так:

Понаблюдаю ещё.

UPD: htop интересней стал:

Условия разные.

  1. На первом скрине опрашивали 2 порта, на втором - 4.
  2. На первом скрине было много публикаций в MQTT (mosquitto и wb-mqtt-db создавали существенную нагрузку), на втором, видимо, меньше.
  3. Нагрузка от wb-rules разная. Возможно, тоже с числом сообщений в MQTT связано.

Я сразу написал, что был оптимизирован именно опрос, и в ситуации с первого скрина эффект будет ограниченный.

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

Та же конфигурация, что в сообщении https://support.wirenboard.com/t/novaya-logika-parametrov-oprosa-wb-mqtt-serial-v-wb-2204/11427/17:

Также прикладываю конфиг:
wb-mqtt-serial.conf (33.5 КБ)

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

  1. Можно htop в древовидном представлении?
  2. Хочется посмотреть сообщения в MQTT, чтобы понять, что и как часто публикуется.
mosquitto_sub -v -t /devices/#

htop:

MQTT:
mosq.log (339.0 КБ)

Видно, что публикуется всё, что меняется: температура, показания счетчика и т.д. И теперь понятно, почему с уменьшением устройств/портов нагрузка растет: чем меньше устройств опроса, тем чаще опрашивается тот же MAP3E и тем чаще публикуются MQTT и DB. Собственно тут и возвращаемся к первому моему вопросу: необходимо иметь возможность ограничивать частоту опроса порта/устройства/параметра.

Сейчас это можно сделать через read_period_ms, но он задаётся только на уровне каналов. Обсудим с коллегами, что можно тут доработать, либо вернуть часть старых параметров.

Ещё раз: read_period_ms - это “не реже, чем”. Таких каналов на всю систему действительно немного, не больше десятка. Но гораздо больше каналов и устройств, где необходима установка “не чаще, чем”. Опрос таких каналов по принципу “best effort” лишь бессмысленно грузит и затормаживает систему. Я попробовал оставить только MAP3E и WB-MS (то есть модули, у которых каналы меняются постоянно, при каждом новом опросе новое значение) и в итоге система тормозила так, что WebUI перестал отвечать. Пришлось принудительно убивать процессы.

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

Здравствуйте!
Сейчас еще пока доступен (хоть и объявлен устаревшим) для устройства и порта параметр Read rate limit (ms) - опрашивать не чаще чем:

Получилось ли решить задачу?

Нет. Load average ниже 4-х и загрузку процессора ниже 90% опустить не удалось.

Вы пробовали установить пакет с исправлениями, как описано в сообщении выше?

Пробовал, существенных изменений не заметил: Новая логика параметров опроса wb-mqtt-serial в wb-2204 - #20 от пользователя Dmitry_Matsnev

Извиняюсь, упустил из виду.
А параметр Read rate limit (ms) не меняет ситуацию?

Меняет. Именно с его помощью, а также установкой read_period_ms = 5000 для часто меняющихся топиков удалось понизить load_average до 3-4 и среднюю загрузку CPU до 80-90%. И это пока при небольшом количестве правил в wb-rules. Меня беспокоит в этой ситуации отсутствие запаса для реализации правил - я планирую управление теплыми полами, водоснабжением, отоплением, вентиляциией, кондиционерами, то есть будет много скриптов и будет добавлено еще несколько модулей WB и >20 1-W датчиков, а также на шину modbus еще повиснут шесть кондиционеров и 11 ПУ-3 от cityron. А сейчас уже, например, лишь добавление телеграм-бота приводит к постоянной 100% нагрузке CPU и приходится его опрос увеличивать до 10 сек, чтобы снизить нагрузку. То есть ресурс контроллера уже полностью исчерпан.

Видимо, для моей конфигурации WB6 не подходит и надо его менять на WB7, но и тут засада. У вас нет их в наличии, нет трейд-ин, и паровозом ещё и модем 4G надо менять… В итоге +23 тысячи рублей и месяц ожидания в лучшем случае… и откатываться на 2201 грустно.

1 лайк

Да, и ещё забыл добавить: процессору также полегчало после

persistence false

в /etc/mosquitto/mosquitto.conf. Вынужден был это сделать после появления ошибок типа “MQTT token wait timeout” по рецепту из Перестают выполняться правила [wbgo_mqtt] MQTT token wait timeout: *mqtt.PublishToken - #3 от пользователя Explorerol

Переехал на WB7, пока похожих проблем нет

Эта тема была автоматически закрыта через 7 дней после последнего ответа. В ней больше нельзя отвечать.