Самая “тяжелая” операция - публикация MQTT-топиков. Я бы посмотрел первым делом, кто там больше всех публикует - как правило наталкивает на мысль, куда дальше копать.
Полезная информация, также жду информацию по методам тестирования от @DmitryKur
Добрый день!
Вот что порекомендовали коллеги:
Если нужно просто нагрузить CPU, то поможет stress -c 4 (stress надо установить apt install’ом).
Память можно продиагностировать через memtester (его и используем).
Эти тесты не помогут вам получить полезную информацию о вышеописанной проблеме.
В вашей ситуации контроллер перезагружается не от перегрева, а из-за программного сбоя, вызванного при работе определенного ПО.
Из диагностического архива сложно еще какие-нибудь выводы сделать? Мы продолжаем тестировать, у нас около 40 инсталяций работают с нашим ПО, пока подобных проблем не встречали, дай Бог и не встретим. Может какое-то ПО криво встало, логов еще не хватает блин.
Укажите пожалуйста на конкретный программный сбой, если такая возможность имеется.
Не конктреное ПО, а просто по какой информации из диагностического архива вы сделали такой вывод
Добрый день!
По какой-то причине был повреждён корневой раздел файловой системы:
[ 0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait ro
[ 3.544536] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[ 3.551866] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
Точную причину установить не удалось.
По моему опыту, установленное стороннее ПО нередко становится причиной перезагрузок и сбоев — тем более мы с вами выяснили, что на данном контроллере оно существенно нагружает процессор.
Лучший способ проверить работоспособность самого контроллера — исключить наиболее вероятные факторы и убрать все лишнее.
В данном случае я бы сделал резервную копию и выполнил бы сброс до заводских настроек по инструкциям:
После этого следует проверить работу контроллера с тем же количеством опрашиваемых устройств — сначала без установки стороннего ПО, а затем с ним.
Мы потестировали нагрузку на контроллер нашим ПО, ничего существенного не выявили.
Может я повредил как-то другими махинациями корневой раздел, сброшу настройки без проблем. После сброса как проверить корневой раздел или просто диаг архив пустого контроллера к вам?
Если вы уверены, что ваше ПО не повлияло на работу контроллера, то давайте диагностировать без него.
После сброса настройте опрос устройств и понаблюдайте. Если проблема проявится, вышлите диагархив.
Пока не могу ничего сказать про наше ПО. Надеемся с ним все хорошо. Если с ним будет проблема, то все наши клиенты прибегут к нам)
Я планирую вычистить контроллер, немного потестить, далее установить его к себе домой, буду смотреть. Если ситуация повторится, буду собирать больше логов
1 Like
Добрый день!
Как проходит тестирование?