Das System ist Linux (Gentoo x64), der Code ist C ++. Ich habe eine Daemon-Anwendung, von der mehrere Instanzen auf demselben Rechner laufen. Die Anwendung ist selbst Multithread. Seit einiger Zeit beobachte ich seltsame Verzögerungen in seiner Leistung.
Nachdem ich etwas Debugging-Code eingegeben hatte, kam ich auf eine komische Sache, wenn mehrere Instanzen des Daemons buchstäblich gleichzeitig blockieren, was angeblich durch einen externen Grund oder etwas verursacht wurde. Um es ganz einfach zu machen, habe ich eine Sequenz wie folgt:
std::list::push_back() / pop_back() auf (d. h. sehr einfache Mathematik) Von Zeit zu Zeit sehe ich deutlich, dass die obige Sequenz in mehreren unabhängigen (!) Prozessen in Schritt 2 (oder wahrscheinlich in Schritt 4) für einige wirklich übermäßige Zeit in Bezug auf die Mathematik in Schritt 3 (z. B. 0,5 - 1,0 Sekunden). Als Beweis sehe ich, dass t2 in den Protokollen für alle Prozesse buchstäblich gleich ist (anders in einigen Mikrosekunden). Es sieht so aus, als ob einige Threads der Prozesse zu relativ unterschiedlichen Zeiten in den Abschnitt eintreten (ich kann deutlich 0.5 - 1 Sekunden Unterschied für t1 sehen), den Mutex sperren und entsperren, nachdem sie angeblich verbraucht haben Unangemessene Menge an Zeit im Schloss nach dem Protokoll ( t2 - t1 Unterschied). Sieht für mich gruselig aus.
Die Manifestation des Problems ist relativ selten, etwa einmal 5-10 Minuten unter mäßiger Belastung. Im Test werden keine NTP-Zeitverschiebungen protokolliert (das war eigentlich meine erste Idee). Wenn es NTP wäre, gäbe es keine tatsächlichen Verzögerungen im Dienst, nur falsche Zeiten im Protokoll.
Wo fange ich an? Beginne ich mit der Optimierung des Schedulers? Was kann theoretisch einen gesamten Multithread-Prozess unter Linux blockieren?
Tags und Links c++ linux-kernel scheduler mutex blocking