Добрый день, у меня на функционирующем объекте контроллер вчера ночью просто выключился. Пару дней назад контроллер пару раз перезегружался, заметили не сразу. То есть проблема вылезала периодически
WB 7 (7.4.3A1IND 1D/H-1G2)
wb-2507 stable
Грешу на бесконечный мусор в логах со штор (5 шт dt82tv), не задал им крайние положения(с периодичностью в милисекунды).
Из-за мусорных логов, не нашел нормальные логи, ведущие к проблеме. Вижу только бесконечный мусор, далее пробел в 3 часа и далее как я физически передернул контроллер по питанию.
Может ли быть такое из-за логов? Логи же подчищаются и не забивают память контроллера?
Выдача journalctl --disk-usage
Указывала на 482.6 Мб, что характерно другим контроллерам тоже)
нашел логи дампа, подскажите пожалуйста источник проблемы
log.txt (11,9 КБ)
Добрый день!
Контроллер может перезагружаться по ряду причин:
- Нестабильное питание — просадки напряжения питания ниже допустимого значения могут вызвать перезагрузку.
- Нехватка места на eMMC.
- Зависание программ и сервисов — сработает watchdog, которые перезагрузит контроллер.
- Перезагрузка вызвана пользователем, например, командой
shutdown -r now.
Сперва стоит проверить качество питания: уровень напряжения, отсутствие «просадок». Попробуйте подключить контроллер к другому блоку питания.
Если питание стабильно, то причину перезагрузки ищите в сообщениях watchdog и ядра ОС Linux (dmesg). Если контроллер перезагружается в цикле и вы не можете попасть в консоль, попробуйте отключить watchdog.
Понадобится больше информации о проблеме.
Для диагностики проблемы пришлите, пожалуйста, архив с диагностической информацией контроллера. Создание архива описано в документации.
После этого:
Отключите временно порт на котором, предполагаете, что есть проблема, которая приводит к перезагрузкам.
прокомментируйте пожалуйста прикрепленный лог
он не перезагрузился в послдений раз, просто отключился
приложен диагностический архив, доступен только сотрудникам поддержки
(213,1 КБ)
есть какой-то полупустой диаг архив, выдача с веб интерфейса
Благодарю!
Пока анализирую архив, дайте информацию по питанию.
Отключите все подключённые устройства от контроллера.
вольтаж 27.7, стоит БП на 100Вт. Устройств много, но на них нет предпосылок недостаточности питания
проблема повторяется очень редко, сейчас например все работает нормально
10 модулей wb-mr6c
3 wb led
2 wbio-di
2 r10a8
16 m1w2
5 wb-mir
Подскажите, что это за стороннее ПО установлено на контроллер?
PID PPID CMD %MEM %CPU TIME
4180 1907 /mnt/data/makesimple/jdk/bi 37.9 5.0 00:38:50
13444 1 /mnt/data/abromSoftware/jav 7.4 102 00:00:33
это наше ПО, вот и пытаемся понять оно ли грузит или дело в контроллере)
вижу, судя по всему оно и съело 102% CPU?
это скорее всего в момент загрузки ПО, фактически потребление
Проблема перезагрузок, с большой вероятностью, в этом.
Предлагаю остановить работу вашего ПО и проверить работу контроллера.
А что это за ПО?
Понаблюдайте за потреблением ресурсов перед перезагрузкой или выключением.
Это ПО для написания логик. Есть пару типов логик, heat, IRCONDITIONER и т.д.
Что удивительно, наше ПО даже на вб6 нормально работает, подобных отключений нет. Разработку мы ведем тоже на вб6. Я послежу еще за загрузкой, забрал контроллер в офис, есть ли какие методики тестирования цпу, хочу погрузить без нашего ПО, посмотрю как себя поведет контроллер.
Пока вообще непонятно куда копать)
Как работает ваше ПО мне неизвестно, но видно, что оно оказывает влияние на загрузку ресурсов.
Отключите все модули и стороннее ПО, как я писал выше — этим вы во многом упростите диагностику.
Тесты ресурсов я не использовал, но уверен, что для linux подобное можно найти. Только не понимаю их смысл, в данном случае могут не воспроизвести проблему.
Ок, я отключу наше ПО, оставлю хотя бы SprutHub. Оставлю на продолжительное время для тестов.
Если же убрать все, включая SprutHub, боюсь это нереально идеальные условия, нам нужно выявить что оно нормально работает с известным вам ПО. Зачем нам проводить тесты на пустом контроллере без загрузки.
Или может вы подскажете или предоставить ваши проверенные тесты нагрузки на ЦПУ, чтобы мы погоняли контроллер на них.
Так мы точно узнаем локализацию проблемы.
Или может вы подскажете или предоставить ваши проверенные тесты нагрузки на ЦПУ, чтобы мы погоняли контроллер на них.
Узнаю у коллег, как можно протестировать.
Судя по скриншоту - основной потребитель ресурсов.
