Нет там сотен в секунду. Дай бог 1 раз в 30 секунд. А как посмотреть буферы? Есть у брокера диагностика?
Я так смотрю - можно на глаз оценить, сколько сообщений сыплется
P.s․ это производственный объект, и сами можете видеть, сколько там топиков. Я посмотрел, сыплется 30-50 сообщений в секунду, и при этом нагрузка на проц. порядка 40%, память наполовину свободна, load average около 2. Т.е. даже для WB7 c 1 ГБ памяти это не нагрузка.
я не знаю
Можно сбрасывать только буфер без перезагрузки брокера?
Думаю, что нет.
Думаю, стоит отключить и publish и проверить. А потом прицельно уже выполнять отладку этого правила. Так мы сможем понять, сохраняется ли проблема c WB-MAI6, или нет. Если сохраняется, то можно продолжать далше поиск неисправностей и отладку. Если не сохраняется и WB-MAI6 сам по себе работает так, как от него и ожадается, то уже разбираться с publish.
всё-таки всё упирается в загрузку системы - отключил wb-rules, wb-mqtt-serial, запустил ваш скрипт - реагирует сразу, запустил wb-rules и скрипт - реагирует сразу (avg 2.45), запустил wb-mqtt-serial - сразу пошли увеличивающиеся задержки (avg 5.83), отключил wb-rules - реакция опять нормализовалась (avg 2.17), publish ни в каком виде не использовал…
итого wb-rules + wb-mqtt-serial на wb6 полностью кладут систему… при чём это видимо именно этот контроллер такой, на другом wb6 контроллере, где я попробовал (хотя он сильно больше загружен устройствами), эта проблема так явно не проявлялась, задержка присутствовала, но не в минутах, а в секундах…
может как-то память можно потестировать и диск? может где-то в них затык?
Смотрите, wb-rules без wb-mqtt-serial не работает, поэтому логично предположиить, что движок “виноват”. Мне кажется, что отключение правил и их постепенное включение, как я выше писал, должно помочь выявить “негодяя”. Попробуйте.
Память и диск сложно проверить полностью. Ошибки бы давали знать о том, что с ними что-то не в порядке. Можно проверить память с помощью memtester или установить hdparm и проверить скорость чтения с диска hdparm -ft /dev/mmcblk0p6, остановив wb-rules и wb-mqtt-serial и сравнить с другими контроллерами. Но мне кажется, что проверка правил приведет у выявлению проблемы быстрее.
Кажется я уже писал, что нет паразитного правила. Сейчас ещё раз перепроверил. Запуск пустого wb-rules (вообще без правил) сразу поднимает avg до 4.16 и задержка в передаче данных сразу начинает идти в 23 секунды. Перезапуск подписки на топик через 3 минуты и фиксируемая задержка уже в 29 секунд. Ещё через 3 минуты и задержка уже 45 секунд (avg поднялось до 5.16). Ещё через 3 минуты и задержка 60 секунд. Дальше смотреть не стал, т.к. уже в цифрах получил подтверждение тому, что писал выше. Задержка становиться всё время больше и больше. Всё же видимо что-то с брокером и его буфером. Такое ощущение, что MAI6 отдаёт много данных (10 раз в секунду?), а брокер копит данные и вываливает в топик только раз в секунду.
memtester погонял на 10 Мб - всё ок
hdparm
Timing buffered disk reads: 158 MB in 3.00 seconds = 52.62 MB/sec
сравнил с другим контроллером - аналогичные показатели
А изменения состояния других устройств (входов релейного модуля, например), также отображается с такими же задержками?
На место MAI6 воткнул M1W2 в режиме нажатий, опрос сделал раз в 100 мс и подписался на счётчик. И начала накликивать (быстро) до и после старта wb-rules (без правил). Поведение полностью аналогичное. Пока wb-rules выключен - риал тайм (до 7 нажатий в секунду), подняли wb-rules, появляется задержка.
Данных явно меньше, т.к. данные идут только от действия, а не постоянный замер. Сделал такую проверку. Кликал в течение 2 минут. Изначальная задержка - 11 секунд. Окончания выдачи данных уже через 21 секунду после окончания нажатий.
Следующий раунд первичная задержка 19 секунд. Через минуту первичная задержка 18 сек и после накликивания в течение 1,5 минут, задержка между окончанием накликивания и выдачи данных - 35 секунд. Следующий раунд - первичная задержка 33 секунды.
Т.е. буфер освобождается медленнее, чем заполняется. Если остановить передачу, то ситуация приходит к терпимым 10 секундам. Если не прекращать, то разрыв между началом отдачи данных и получением данных становится катастрофическим. Осталось понять почему не освобождается буфер.
Может есть какая-то глобальная подписка, куда пытаются отдать данные, но она их не принимает и буфер освобождается по тайм-ауту?
Вообще без правил не бывает, есть системные правила, которые нами написаны, и которые wb-rules также выполняет. Если старт wb-rules сразу приводит к такой перегрузке системы - “виновником” могут быть системные правила. Думаю, надо подключаться к контроллеру нашему инженеру и смотреть самому.
@JackDallas согласен?
Я бы еще посмотрел при помощи MQTT-Explorer, сколько сообщений в ед. времени публикуется при остановленных wb-mqtt-serial и wb-rules, при запущенных - чтобы было понимание, с каким потоком данных и от кого мы вообще работаем.
Сейчас, к сожалению, контроллер недоступен в облаке. Как будет восстановлен доступ,я мог бы проверить, но мне нужно будет разрешение от вас на остановку запуск движка и правил.
Вот что даёт MQTT-Explorer при запущенных wb-mqtt-serial и wb-rules
вот что при остановленных (скриншот снят после 5 минут выжидания)
@JackDallas сейчас контроллер должен быть в облаке, запускайте/останавливайте что надо
Спасибо! Вижу контроллер, напишу, как закончу сегодня.
Закончил, но, к сожалению, не обнаружил никаких аномалий. И подписчик тут же получает тестовые mqtt-сообщения, которые я публикую, без каких-либо заметных задержек.
Могу я попросить вас соединить свободные контакты какого-то релейного модуля с каким-либо входом сухих контактов, возможно, так я смогу увидеть то, что наблюдаете вы?
Судя по тому, что я наблюдал, и реле, и сухие контакты должны быть отдельными модулями? Свои внутренние сухие контакты, W2 например, контроллер вроде как без задержек анализирует.
Настроил вам кликер. Это MRM2-mini/NO. Регистратор замыканий M1W2.
Чтобы воспользоваться - сохраняем teststring.js. Он прокликивает 100 раз с задержками в 400 мс (200 мс вкл, 200 мс выкл). В логи кидает каждый клик. Полностью повторяется картина, о которой пишу:
- кликать начинает сразу,
- само прокликивание за 54 сек (данные физического таймера и лога совпадают, можно ориентироваться на лог как на достоверные данные о процессе начала и конца прокликивания),
- начало выдачи из буфера в примерно 3:11 (т.е. через 2 минуты после окончания прокликивания, перед этим был пробный запуск, так что полагаю, что буфер был подзабит),
- окончание выдачи в примерно 6:01 (через 3 минуты после начала выдачи данных из буфера, т.е. в 3 раза дольше чем само действие),
- один клик потерян.
Для подписки на счётчик используйте подписку на устройство “wb-m1w2_11/Input 1 counter” (есть в истории).
Спасибо большое! Сегодня постараюсь продиагностировать и, надеюсь, разобраться наконец.
Прошу прощения, не успел сегодня поэкспериментировать, буду завтра, напишу результат.