Добрый день! Подскажите, пожалуйста, имеется ли какое-то ограничение на количество каналов у виртуальных устройств? А также имеется ли ограничение на число каналов MQTT? (WB 8.5)
Здравствуйте! Я — автоматический помощник техподдержки Wiren Board.
Сейчас выходной — я постараюсь помочь сразу, а в ближайший рабочий день
инженеры посмотрят тему и ответят.
В документации Wiren Board точного численного ограничения на количество каналов виртуального устройства и каналов MQTT для WB 8.5 не нашлось. Жёсткого лимита вида «не более N каналов» для этих объектов не указано; на практике ограничение определяется ресурсами контроллера — оперативной памятью, нагрузкой wb-rules, частотой публикаций и числом подписчиков.
Уточните, пожалуйста:
- Как создаются виртуальные устройства: через
wb-rules, HomeUI или другой сервис? - Какое количество каналов планируется и как часто они будут обновляться?
- Речь идёт о каналах внутри
/devices/...или о количестве MQTT-топиков в целом?
Здесь может понадобиться мнение инженера Wiren Board. Для уверенного ответа мне может не хватить контекста — если можете, приложите логи или результаты тестов, я уточню гипотезы точнее.
Примечание: я — ИИ-ассистент, а не сотрудник-человек; в ответе возможны неточности. Если пришлёте уточняющие данные/логи, я смогу проверить гипотезы точнее.
Устройство создается через wb-rules. Каналов предварительно получается около 2000, однако, обновляться они будут крайне редко, в среднем - не более 5 каналов в минуту.
Добрый день!
Жёстких ограничений на число каналов виртуального устройства в wb-rules нет, как нет и лимита на количество топиков в MQTT-брокере. Погонял у себя на стенде, все работало корректно.
Нагрузка на процессор и память контроллера заметно вырастет, как и время загрузки правил после перезапуска wb-rules. При заявленных 5 обновлениях в минуту запас по производительности большой, но конфигурацию стоит протестировать на своём оборудовании.
Узким местом может оказаться веб-интерфейс, страница «Устройства» с таким устройством будет отрисовываться заметно дольше.
Только отрисовываться или не только? После создания такого набора каналов реакция на нажатие pushbutton происходит примерно через минуту после завершения создания каналов. Причем, даже в случае, если соответствующий устройству список каналов свернут. Последовательные нажатия по началу также проходят с задержкой. Это от тяжести визуализации всё происходит?
Нет, это не из-за визуализации.
Каналы виртуального устройства существуют как топики в MQTT-брокере, и создание 2000 каналов означает отправку брокеру большого количества сообщений. При этом wb-rules сам подписан на брокер, все эти сообщения возвращаются ему обратно и требуют обработки. Обрабатывается всё в одной очереди, и нажатие кнопки встаёт в конец этой очереди. Как только очередь разберётся, отклик вернётся к обычному, задержек быть не должно. Такое поведение будет повторяться при каждом перезапуске wb-rules.
А-а-а, понятно…
А возможно ли как-то понять, что очередь опустела?
Можно посмотреть по загрузке процессора движком правил, каких то точных методов не знаю(
Довольно “интересный” результат вижу сейчас, хотя особой активности на устройстве нет
root@wirenboard-AXCFBMYW:~# ps -o pid,pcpu,pmem,etime,cmd -C wb-rules
PID %CPU %MEM ELAPSED CMD
3273307 67.1 4.8 1-18:40:16 /usr/bin/wb-rules -http 127.0.0.1:9090 -syslog -editdir /etc/wb-rules/ /usr/share/wb-rules-system/rules/ /etc/wb-rules/ /usr/share
root@wirenboard-AXCFBMYW:~#
Или я не так смотрю, что вижу 67%?
ps показывает не текущую загрузку, а среднюю за всё время работы процесса, а он у вас запущен уже почти двое суток. Поэтому 67% ни о чём не говорят применительно к текущему моменту. Смотрите через top
Тут, насколько понимаю, картина не сильно лучше
root@wirenboard-AXCFBMYW:~# top -b -n 1
top - 15:23:31 up 9 days, 20:18, 1 user, load average: 3.76, 2.98, 2.72
Tasks: 167 total, 2 running, 165 sleeping, 0 stopped, 0 zombie
%Cpu(s): 41.1 us, 8.2 sy, 0.0 ni, 45.2 id, 0.0 wa, 4.1 hi, 1.4 si, 0.0 st
MiB Mem : 1984.9 total, 149.1 free, 444.3 used, 1391.4 buff/cache
MiB Swap: 256.0 total, 255.5 free, 0.5 used. 1457.5 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3273307 root 20 0 2730452 98948 20352 S 94.1 4.9 1834:43 wb-rules
Я тестировал на чистом контроллере, где кроме виртуального устройства на 2000 каналов не было никаких других правил. В таких условиях движок правил занимал больше одного ядра. После этого загрузка падала до 10%, реакция на нажатие вернулось в нормальное состояние и не менялось.
Полагаю, что на контроллере работает не только код с виртуальными устройствами, и источник высокой нагрузки надо искать в остальных правилах.
Последовательно запуская top вижу колебания загрузки от 35 до 100 процентов. Среднее похоже как раз на ранее проявлявшееся 60. Вроде бы, сильно нагруженных правил нет, как и какой-то затратной математики.
Как в этом варианте лучше искать источник высокой загрузки помимо попыток последовательного отключения правил?
Ну как вариант, еще можно посмотреть по трафику MQTT. Загрузка движка правил определяется в основном количеством входящих сообщений. Даже простое правило, подписанное на часто меняющийся канал, работает непрерывно.
А как можно оценить трафик MQTT?
Можно командой ниже, она за 10 секунд соберёт трафик и покажет топ-20 топиков по числу сообщений:
mosquitto_sub -t '#' -F '%t' -W 10 | sort | uniq -c | sort -rn | head -20
Спасибо. Сделанные последовательно несколько выборок с интервалом примерно в полминуты дали вот такой результат:
root@wirenboard-AXCFBMYW:~# mosquitto_sub -t '#' -F '%t' -W 10 | sort | uniq -c | sort -rn | head -20
Timed out
21 /devices/wb-msw-v3_20/controls/Current Motion
15 /devices/wb-msw-v3_34/controls/Sound Level
15 /devices/wb-msw-v3_20/controls/Sound Level
14 /devices/wb-map6s_1/controls/Q 3
14 /devices/wb-map6s_1/controls/P 2
14 /devices/Water/controls/sewageCompressorPower
14 /devices/meta_error_test/controls/value
14 /devices/meta_error_test/controls/topic
14 /devices/meta_error_test/controls/datetime
13 /devices/wb-map6s_1/controls/Urms
13 /devices/wb-map6s_1/controls/P 3
13 /devices/wb-map6s_1/controls/Frequency
13 /devices/wb-adc/controls/V5_0
13 /devices/Water/controls/waterPumpPower
12 /devices/wb-map6s_1/controls/Phase angle 2
11 /devices/wb-map6s_1/controls/Q 2
11 /devices/wb-map6s_1/controls/Phase angle 3
11 /devices/wb-mai6_186_2/controls/Uptime
10 /devices/WB_Power/controls/externalPowerSupplyBatteryVoltage
10 /devices/wb-map6s_1/controls/S 2
root@wirenboard-AXCFBMYW:~# mosquitto_sub -t '#' -F '%t' -W 10 | sort | uniq -c | sort -rn | head -20
Timed out
20 /devices/meta_error_test/controls/value
20 /devices/meta_error_test/controls/topic
20 /devices/meta_error_test/controls/datetime
17 /devices/wb-msw-v3_20/controls/Current Motion
15 /devices/wb-msw-v3_34/controls/Sound Level
15 /devices/wb-msw-v3_20/controls/Sound Level
15 /devices/wb-map6s_1/controls/Q 3
15 /devices/wb-map6s_1/controls/Phase angle 2
15 /devices/wb-map6s_1/controls/P 2
15 /devices/Water/controls/sewageCompressorPower
13 /devices/wb-map6s_1/controls/Frequency
12 /devices/wb-msw-v3_10/controls/Current Motion
12 /devices/wb-map6s_1/controls/Urms
12 /devices/wb-map6s_1/controls/Q 2
11 /devices/wb-map6s_1/controls/P 3
11 /devices/wb-mai6_186_2/controls/Uptime
11 /devices/wb-adc/controls/V5_0
11 /devices/Water/controls/waterPumpPower
10 /devices/wb-map6s_1/controls/Phase angle 3
9 /devices/wb_ups_v3_156/controls/battery_voltage
root@wirenboard-AXCFBMYW:~# mosquitto_sub -t '#' -F '%t' -W 10 | sort | uniq -c | sort -rn | head -20
Timed out
19 /devices/wb-msw-v3_20/controls/Current Motion
15 /devices/wb-msw-v3_20/controls/Sound Level
14 /devices/wb-msw-v3_34/controls/Sound Level
14 /devices/wb-map6s_1/controls/Q 2
14 /devices/wb-map6s_1/controls/P 2
14 /devices/wb-mai6_102/controls/IN 5 P Current
14 /devices/Water/controls/sewageCompressorPower
13 /devices/wb-map6s_1/controls/Phase angle 2
12 /devices/wb-map6s_1/controls/Q 3
12 /devices/wb-map6s_1/controls/Phase angle 3
12 /devices/wb-map6s_1/controls/P 3
12 /devices/Water/controls/waterPumpPower
11 /devices/wb-map6s_1/controls/Frequency
11 /devices/wb-mai6_186_2/controls/Uptime
10 /devices/wb_ups_v3_156/controls/battery_voltage
10 /devices/WB_Power/controls/externalPowerSupplyBatteryVoltage
10 /devices/wb-msw-v3_20/controls/Temperature
10 /devices/wb-msw-v3_20/controls/Humidity
10 /devices/wb-map6s_1/controls/Urms
10 /devices/wb-adc/controls/V3_3
root@wirenboard-AXCFBMYW:~#
Т.е. получается, что относительно высокая интенсивность публикации значений имеет место преимущественно по тем каналам MQTT, где речь идет о нормальной флуктуации текущих значений показаний аналоговых сенсоров. Правильно я понимаю?
Да, всё верно, основная масса это штатная флуктуация аналоговых показаний, ничего лишнего в этом трафике нет. Суммарные около 50 сообщений в секунду вполне объясняют наблюдаемую загрузку движка правил, если на эти каналы подписаны правила: дело не в одном проблемном правиле, а в общем количестве обрабатываемых событий.
Данный “слепок” взят в режиме, когда система в целом фактически находится в состоянии покоя. Получается, что в варианте “нормативной” работы показатели будут еще выше, причем радикально.
По-хорошему, стоило бы иметь возможность фильтровать/усреднять аналоговые показания или на устройстве, или в драйвере. Ну, или, хотя бы, точность значений ограничивать. Те же сотые доли вольта в электроустановках 0,4кВ в 95% применений реального значения не имеют…
Что до подписанных на события правил, то подписки есть примерно на половину из них. Подумаем над тем, чтобы вовсе не опрашивать те значения, которые по факту не используются, но, при этом, регулярно обновляются.
Да, это вполне разумный путь. Отключение опроса каналов, которые фактически не используются снизит нагрузку на движок правил.