2016-05-25 4 views
0

System ist ein eingebetteter Linux/Busybox-Kern auf einer kleinen Embedded-Platine mit einem laufenden Web-Server (Boa).Bestimmung der Ursache für Verzögerung/Pause - Kernel-Scheduler usw.

Wir sind eine hohe Latenz in Antworten von dem Web-Server zu sehen - manchmal> 500 ms für keinen guten Grund, also habe ich graben worden ...

Auf reichlich Streu Debug druckt über den gesamten Code scheint es zu kommen bis auf den ganzen Prozess nur ... für eine Weile stoppen, in einer Weise, die ich nur annehmen kann, muss der Prozess/Thread von einem anderen Prozess unterbrochen werden.

Mit print Anweisungen und clock_gettime(), um die Zeit für die Verarbeitung einer Anfrage zu berechnen, kann der Code den unteren Rand einer while() Schleife erreichen (Eingabe analysieren), etwas wie "Time so far: 5ms" und dann die nächste Zeile an der Anfang der Schleife wird "Time so far: 350ms" drucken - und alles, was der Code zwischen dem unteren Rand der Schleife und dem ersten Druck zurück an der Spitze tut, ist eine grundlegende Überprüfung in den Zeilen while(position < end), es hat nichts kompliziertes, das es halten könnte.

Es gibt keine IO-Blockierung, die Daten, die es analysiert, sind bereits angekommen, und es macht keine externen Anrufe oder wandert in komplexe Funktionen ab.

Ich habe dann untersucht, ob der Kernel-Scheduler (CFS in unserem Fall) Dinge halten kann, Anrufe zu clock() hinzufügen (Prozessorzeit statt Wanduhr) und wieder Berechnung der Zeitunterschiede Vs Prozessorzeit verwendet kann ich das sehen Die Wanduhr-Zeitverzögerung kann über 300 ms von einer Schleife zur nächsten verlaufen, aber die gemeldete Prozessorzeit (die eine Auflösung von ~ 10 ms zu haben scheint) ist eher 50 ms.

Also, das schlägt vor, dass der Taskplaner den Prozess für Hunderte von Millisekunden auf einmal hält. Ich habe die scheduler granularity and max delay überprüft und es ist nicht in der Nähe von 100ms, Scheduler Latenz ist auf 6ms zum Beispiel festgelegt.

Irgendwelche Ratschläge, was ich jetzt tun kann, um das Problem aufzuspüren - Prozesse zu identifizieren, die die CPU für> 100ms beschämen könnten, zu messen/zu verfolgen, was der Scheduler macht, etc.?

Antwort

0

Zuerst sollten Sie versuchen, Ihr Programm mit strace auszuführen, um zu sehen, ob irgendwelche Systemaufrufe die Dinge aufhalten.

Wenn das mehrdeutig ist oder nicht hilft, würde ich vorschlagen, dass Sie versuchen, den Kernel zu profilieren. Sie könnten versuchen OProfile

Dies wird ein Call-Diagramm erstellen, das Sie analysieren können und sehen, was passiert.

Verwandte Themen