Таким образом, уменьшение количества каналов rs485 и количества опрашиваемых устройств приводит к существенному увеличению нагрузки.
- Можно
htopв древовидном представлении? - Хочется посмотреть сообщения в 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 дней после последнего ответа. В ней больше нельзя отвечать.