Нахождение проблем задержки (остановы) во встроенных системах Linux
У меня есть встроенная система Linux, работающая на плате Atmel AT91SAM9260EK, на которой у меня есть два процесса, работающие в приоритете в реальном времени. Процесс менеджера периодически "проверяет с помощью ping-запросов" рабочий процесс с помощью очередей сообщений POSIX для проверения состояния рабочего процесса. Обычно ping туда и обратно берет приблизительно 1 мс, но достаточно редко он берет намного дольше - приблизительно 800 мс. Нет никаких других процессов, которые работают в более высоком приоритете.
Кажется, что останов может быть связан с регистрирующимся (системный журнал). Если я прекращаю регистрироваться, проблема, кажется, уходит. Однако это не имеет никакого значения, если файл журнала находится на JFFS2 или NFS. Никакие другие процессы не пишут в "диск" - просто системный журнал.
Что инструменты доступны мне, чтобы помочь мне разыскать, почему эти остановы происходят? Я знаю о latencytop и буду использовать это. Есть ли некоторые другие инструменты, которые могут быть более полезными?
Некоторые детали:
- Версия ядра: 2.6.32.8
- libc (функции системного журнала): uClibc 0.9.30.1
- системный журнал: busybox 1.15.2
- Никакая область подкачки не настроена [добавленная в редактировании]
- корневая файловая система находится на tmpfs (загружена из initramfs) [добавленный в редактировании]
1 ответ
Проблема в (как вы сказали) syslogd. Пока ваш процесс работает с приоритетом RT, syslogd имеет значение , а не . Кроме того, syslogd не блокирует свою кучу и может (и будет) выгружаться ядром, особенно с очень небольшим количеством «клиентов».
Что вы можете попробовать:
Запустите другой поток для управления очередью с приоритетами, пусть этот поток общается с системным журналом. В этом случае логирование будет просто захватом блокировки и вставкой чего-либо в список. При наличии всего двух подписчиков не стоит тратить много времени на приобретение мьютекса.
Не используя системный журнал, внедрите собственное ведение журнала (в основном первое предложение, за исключением разговора с системным журналом).
У меня была похожая проблема, и моей первой попыткой исправить ее было изменение самого syslogd, чтобы заблокировать его кучу.Это была катастрофа. Затем я попробовал rsyslogd, который немного улучшил, но у меня все еще были случайные пики задержки. В итоге я просто реализовал собственное ведение журнала с использованием очереди приоритетов, чтобы гарантировать, что более важные сообщения действительно будут записаны первыми.
Обратите внимание: если вы (вообще) не используете свопинг, кратчайший путь к исправлению этого, вероятно, заключается в реализации вашего собственного журналирования.