После обновления на булсай у контроллера высокая нагрузка

[VitP]

После обновления на булсай, на следующий день на контроллере отвалились сетевые интерфейсы. Но не в одночасье, а через какое-то время.
Перезагрузка занимает довольно продолжительное время (это когда светодиод светит красным) .
В итоге с сетью удалось разобраться (на форуме подсказали) . У меня подключен к точке доступа по WiFi и по кабелю (что в общем случае бессмысленно, но при таком подключении - не работает), у одного из интерфейсов указал метрику - заработало и с двумя подключениями.
Но контроллер все время чем-то занят, настолько что иногда не удается дождаться отклика веб интерфейса. На картинке видно, что wb-rules нагружает на 95%, но это просто неудачный кадр - в основном в районе 145 колеблется. Удалял все правила - ожидаемо опускается до 40%, но не до 0!

diag_output_AMFACU7_2022-10-25-11.08.16.zip (164.4 КБ)

[AlexandrD]

Подскажите, с какого релиза вы переезжали?

[VitP]

С последнего testing, который не bullseye.
Выполнил обновление (как было сказано в инструкции), перезагрузился, а затем выполнил переход.

[webconn]

Добрый день!

Посмотрел логи, там действительно была ошибка в одном из ваших правил, которая повторялась циклически:

Oct 25 02:16:48 wirenboard-AMFACU7 wb-rules[2289]: ERROR: [rule error] ECMAScript error: TypeError: call target not an object
                                                           duk_js_executor.c:2761
                                                           calcP /etc/wb-rules/electric-meter.js:63
                                                           anon /etc/wb-rules/electric-meter.js:107 preventsyield
                                                           call  native strict preventsyield
                                                           anon /usr/share/wb-rules-system/scripts/lib.js:239 preventsyield

После удаления правила это перестало повторяться.

После перезапуска контроллера (или сервиса wb-rules отдельно) не становится лучше?

[VitP]

Указанное правило и ошибка в нем - результат попытки оптимизации, после того как выяснилось что проблема связана с wb-rules.
Сейчас все правила вернул назад, но особо легче не стало, контроллер по прежнему чем-то занят.
Прилагаю очередной скриншот с загрузкой (это после вчерашнего вечернего обновления). Могу приложить правила, на нем крутящиеся (их 2 и они “детские”, сама конфигурация контроллера с устройствами - “детская”).
До перехода на bullseye, таких проблем не наблюдалось. Правда я и за производительностью не следил, потому что не было в этом необходимости.

[VitP]

После сегодняшнего обновления, в логе повторяется фрагмент. Так же прилагаю диагностическую информацию.

diag_output_AMFACU7_2022-10-26-20.44.04.zip (166.5 КБ)

[Explorerol]

Здравствуйте! Получилось ли решить проблему?
Во это в логе довольно странно:

Oct 26 20:27:09 wirenboard-AMFACU7 systemd[1]: Stopping MQTT Rule engine for Wiren Board...
Oct 26 20:27:09 wirenboard-AMFACU7 wb-rules[2337]: INFO: [engine] Stop main loop
Oct 26 20:27:09 wirenboard-AMFACU7 wb-rules[2337]: panic: send on closed channel
Oct 26 20:27:09 wirenboard-AMFACU7 wb-rules[2337]: goroutine 622268 [running]:
Oct 26 20:27:09 wirenboard-AMFACU7 wb-rules[2337]: github.com/wirenboard/wb-rules/wbrules.(*RuleEngine).CallSync(0xa38100, 0xb0ad80)
Oct 26 20:27:09 wirenboard-AMFACU7 wb-rules[2337]:         github.com/wirenboard/wb-rules/wbrules/engine.go:912 +0xf4
Oct 26 20:27:09 wirenboard-AMFACU7 wb-rules[2337]: github.com/wirenboard/wb-rules/wbrules.(*ESEngine).esWbSpawn.func1(0xa9fe80, 0x3, 0x3, 0x100001, 0x0, 0xb1a950, 0xa2e910, 0xb4a0a0)
Oct 26 20:27:09 wirenboard-AMFACU7 wb-rules[2337]:         github.com/wirenboard/wb-rules/wbrules/esengine.go:2054 +0x230
Oct 26 20:27:09 wirenboard-AMFACU7 wb-rules[2337]: created by github.com/wirenboard/wb-rules/wbrules.(*ESEngine).esWbSpawn
Oct 26 20:27:09 wirenboard-AMFACU7 wb-rules[2337]:         github.com/wirenboard/wb-rules/wbrules/esengine.go:2047 +0x1e8
Oct 26 20:27:10 wirenboard-AMFACU7 systemd[1]: wb-rules.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Oct 26 20:27:10 wirenboard-AMFACU7 systemd[1]: wb-rules.service: Failed with result 'exit-code'.
Oct 26 20:27:10 wirenboard-AMFACU7 systemd[1]: Stopped MQTT Rule engine for Wiren Board.

[VitP]

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

Еще есть такое поведение: открываешь в проводнике страницу контроллера, он как-бы откликнулся - даже меню с лева нарисовал, но меню сильно урезанное. В нем совсем нет панелей и соответственно не загружается панель по умолчанию. Перехожу в раздел устройств - вроде бы все на месте. Нахожу датчик температуры - перехожу к просмотру истории. На этом моменте контроллер подвисает - крутится бублик и ничего не происходит. Рефреш страницы не всегда помогает, иногда с очисткой кэша срабатывает.

Активных работ по настройке пока не требуется, поэтому не активно обновляюсь и жду версии которая при перепрошивке сделает разделы на весь накопитель.

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

[Explorerol]

По описанию пока сложно что-то подсказать. Если есть проблема, то лучше присылайте видео или хотя бы скриншоты.

[vaprol]

Та же проблема после обновления на bullseye - высокая загрузка CPU.

Причиной, судя по всему, является wb-rules. В логах wb-rules.service - ничего нет, что он делает - непонятно. Правилами не пользуемся, системные wb-rules-system не затронуты.

---

Если wb-rules остановить - ситуация выглядит лучше

---

В чате Ваш сотрудник порекомендовал убрать системные правила и посмотреть. Да, без них загрузка CPU ниже. Я попытался понять в каком файле дело.
Не смог выявить какой-то строгой зависимости от определённого файла системных правил. По ощущениям казалось, что connections_virtual_devices.js больше всего съедает ресурсов, а также network.js и system.js, но не уверен.
Прикреплю историю средней загрузки CPU 5- и 15-минутной, а также что я менял в это время:
14:30 - присутствут все системные правила
15:42 - удален connections_virtual_devices.js
16:46 - удален network.js
17:53 - удалён system.js
19:09 - удалены все системные правила
20:14 - остановлен wb-rules
21:17 - запущен wb-rules с пустой директорий системных правил
22:19 - добавлен connections_virtual_devices.js
23:20 - убран connections_virtual_devices.js, добавлен network.js
00:30 - убран network.js, добавлен system.js
01:35 - убран system.js, добавлены buzzer.js, hwmon.js, power-class-battery.js, power_status.js, wb-mqtt-dac.js, wbmz-battery.js
08:14 - вернул все системные правила на место

---

Архив также прикрепляю:
приложен диагностический архив, доступен только сотрудникам поддержки (86,8 КБ)

[vaprol]

Коллеги, встречается ли у кого-нибудь подобная проблема после обновления? Или никто не обращает внимания на загрузку ЦП?

@VitP Виталий, удалось ли Вам побороть проблему? Наблюдается ли она до сих пор?

Всё то работает, но загрузка в 0.6-0.7 без wb-rules и 1.2 - с запущенным wb-rules - это в 2 раза больше. Сравнить даже apt update | apt upgrade - без правил выполняется существенно быстрее, да и система в целом работает расторопнее. Тепература ЦП при высокой загрузке, соотвественно, выше, потенциально контроллер просто меньше проживёт в таком режиме, разве не так?

[VitP]

Нагрузка по прежнему высокая. Но сам контроллер (веб интерфейс) стал “отзывчевее”.

Еще заметил, что нагрузка после обновления и перезагрузки обычно выше чем до. Если еще раз перезагрузить становится чуть меньше, но все же непонятно почему такая высокая.

[BrainRoot]

На testing или stable?

[VitP]

На тестинге, обновляюсь ежедневно.

[vaprol]

@BrainRoot

На testing или stable?

У нас stable

[Vyac]

Релиз wb-2304, 4 правила на управление кондиционерами, загрузка 12-15%.
многовато, по сравнению с mqtt-serial, который явно делает больше работы

[BrainRoot]

Воплне нормально, как по мне. Контроллер сделан для того чтобы на нем выполнялись правила ведь… Ну да, 15% одного ядра. Это немного.

[VitP]

Добрый день! Сижу на тестинге (обновлюсь ежедневно). Периодически смотрю что там top показывает - ни разу не было лучше! Т.е. wb-rules обычно “развлекается” на 60-70%.
Вот сегодняшняя сводка.

[BrainRoot]

@VitP

Т.е. wb-rules обычно “развлекается” на 60-70%.

CPU или ядра?

[VitP]

Смотрю на колонку “%CPU”.
Так понимаю, что CPU.

Вот расшифровку нашел - “использование центрального процессора, доля задачи в потреблённом процессорном времени с момента последнего обновления экрана, выражается в процентах от общего времени CPU”