Поиск проблем с задержкой (остановок) во встроенных системах Linux - PullRequest
9 голосов
/ 26 апреля 2010

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

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

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

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

  • Версия ядра: 2.6.32.8
  • libc (функции системного журнала): uClibc 0.9.30.1
  • syslog: busybox 1.15.2
  • Не настроено пространство подкачки [добавлено в правку]
  • корневая файловая система находится на tmpfs (загружена из initramfs) [добавлено в правку]

1 Ответ

2 голосов
/ 26 апреля 2010

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

Что вы можете попробовать:

  • Запустите другой поток для управления приоритетной очередью, попросите этот поток общаться с системным журналом. Ведение журнала тогда будет просто захватить блокировку и вставить что-то в список. При наличии только двух подписчиков не стоит тратить много времени на приобретение мьютекса.

  • Не используя syslog, внедрите собственную регистрацию (в основном первое предложение, за исключением разговора с syslog).

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

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

...