Поиск проблем с задержкой (в стойлах) во встроенных системах Linux

Question

У меня встроенная система Linux, работающая на плате Atmel AT91SAM9260EK, на которой у меня есть два процесса, работающих в режиме реального времени. Процесс диспетчера периодически «пинги» рабочего процесса, используя очереди сообщений POSIX, проверяет работоспособность рабочего процесса. Обычно пинг «туда и обратно» занимает около 1 мс, но очень редко он занимает гораздо больше времени - около 800 мс. Нет других процессов, которые работают с более высоким приоритетом.

Похоже, что стойло может быть связано с протоколированием (syslog). Если я перестаю регистрировать проблему, похоже, уйдет. Однако не имеет значения, находится ли файл журнала на JFFS2 или NFS. Никакие другие процессы не записывают на «диск» - просто syslog.

Какие инструменты доступны мне, чтобы помочь мне отследить, почему эти киоски происходят? Я знаю о latencytop и буду использовать это. Есть ли другие инструменты, которые могут быть более полезными?

Некоторые детали:

• версия ядра: 2.6.32.8
• Libc (Syslog функции): uClibc 0.9.30.1
• системный журнал: BusyBox 1.15.2
• Нет подкачки сконфигурировано [добавлено в править]
• корневая файловая система находится на TMPFS [добавлено в редактировать] (загружается из initramfs)

Answer 1

Проблема (как вы сказали) syslogd. Пока ваш процесс работает с приоритетом RT, syslogd равен , а не. Кроме того, syslogd не блокирует свою кучу и может (и будет) выгружаться ядром, особенно с очень немногими «клиентами».

Что вы могли бы попробовать это:

• Запустить другой поток для управления очередью приоритета, есть что нить поговорить с Syslog. Тогда журнал должен был бы получить блокировку и вставить что-то в список. Учитывая только двух подписчиков, вы не должны тратить много времени на получение мьютекса.

• Не использовать syslog, реализовать свой собственный журнал (в основном первое предложение, минус разговор с syslog).

У меня была аналогичная проблема, и моя первая попытка исправить это было изменение самого syslogd, чтобы заблокировать его кучу. Это было катастрофой. Затем я попробовал rsyslogd, который улучшил некоторые, но у меня все еще были случайные пики латентности. В итоге я просто выполнил собственное ведение журнала с использованием очереди приоритетов, чтобы гарантировать, что сначала были написаны более критические сообщения.

Обратите внимание, что если вы не используете swap (вообще), кратчайший путь к его исправлению, вероятно, реализует ваш собственный журнал.