Ich habe ein Embedded-Linux-System auf einem Atmel AT91SAM9260EK-Board, auf dem zwei Prozesse mit Echtzeit-Priorität laufen. Ein Managerprozess "pingt" periodisch einen Arbeitsprozess mit POSIX-Nachrichtenwarteschlangen, um den Zustand des Arbeitsprozesses zu überprüfen. Normalerweise dauert das Round-Trip-Ping ungefähr 1 ms, aber sehr oft dauert es viel länger - ungefähr 800 ms . Es gibt keine anderen Prozesse, die mit einer höheren Priorität ausgeführt werden.
Es scheint, dass der Stall möglicherweise mit der Protokollierung (Syslog) zusammenhängt. Wenn ich mit der Protokollierung aufhöre, scheint das Problem wegzugehen. Es macht jedoch keinen Unterschied, ob sich die Protokolldatei in JFFS2 oder NFS befindet. Keine anderen Prozesse schreiben auf die "Festplatte" - nur syslog.
Welche Tools stehen mir zur Verfügung, um mir zu helfen, herauszufinden, warum diese Stände auftreten? Ich bin mir der Latenz bewusst und werde das benutzen. Gibt es noch andere nützliche Tools?
Einige Details:
Das Problem ist (wie Sie sagten) syslogd. Während Ihr Prozess mit RT-Priorität ausgeführt wird, ist syslogd nicht . Außerdem sperrt syslogd seinen Heap nicht und kann (und wird) vom Kernel ausgelagert werden, insbesondere bei sehr wenigen "Kunden".
Was Sie versuchen könnten, ist:
Starten Sie einen anderen Thread, um eine Prioritätswarteschlange zu verwalten. Lassen Sie diesen Thread mit syslog sprechen. Die Protokollierung würde dann nur eine Sperre erfassen und etwas in eine Liste einfügen. Bei nur zwei Abonnenten sollten Sie nicht viel Zeit damit verbringen, den Mutex zu erwerben.
Wenn Sie syslog nicht verwenden, implementieren Sie Ihre eigene Protokollierung (im Prinzip der erste Vorschlag, abzüglich der Kommunikation mit syslog).
Ich hatte ein ähnliches Problem, und mein erster Versuch, es zu beheben, bestand darin, syslogd selbst zu modifizieren, um seinen Heap zu sperren. Das war eine Katastrophe. Ich habe dann rsyslogd ausprobiert, was einige verbessert hat, aber ich habe immer noch zufällige Latenzspitzen. Am Ende habe ich meine eigene Protokollierung mithilfe einer Prioritätswarteschlange implementiert, um sicherzustellen, dass mehr kritische Nachrichten zuerst geschrieben wurden.
Wenn Sie Swap (überhaupt) nicht verwenden, implementieren Sie wahrscheinlich den kürzesten Pfad zur Fehlerbehebung, indem Sie Ihre eigene Protokollierung implementieren.