Von Zeit zu Zeit ist unser Linux LAMP-Server (mit PHP-FPM, XFS auf Thin LVM auf HW RAID, Centos8) nicht mehr erreichbar und reagiert nicht mehr auf HTTP(S)-Anfragen.
Über die zentrale Protokollierung haben wir herausgefunden, dass in diesen Fällen die durchschnittliche Auslastung schnell auf Hunderte ansteigt, während immer mehr Prozesse (systemd-journald, PHP-Prozesse, Kernel-XFS/DM-Threads...) in den D-Zustand geraten. Laut iostat und pidstat werden CPU und Festplatte kaum belastet, während die durchschnittliche Auslastung bei etwa 170 liegt, was ziemlich seltsam ist. Aus der Ausgabe von htop/ps geht hervor, dass es weder einen einzelnen noch eine Gruppe von Schurkenprozessen gibt, die dieses Verhalten erklären würden. Es sind einfach Standardprozesse, die auf eine Art „Blockade“ zu stoßen scheinen.
Das einzige andere Merkwürdige bei der Festplattenüberwachung ist, dass iostat während dieser Überlastungsereignisse zeitweise recht hohe w_await-Zeiten für die Partition /var meldet (2500-5000 ms, während andere Partitionen wie /var/log, /var/lib/mysql meist nicht über 10 ms hinauskommen). Diese Partition sollte die meiste Zeit ruhig sein, daher ist nicht klar, warum iostat dort so lange w_await-Zeiten meldet.
Die einzige Lösung besteht dann darin, den Server aus- und wieder einzuschalten.
Dies passiert auf zwei Servern desselben Typs, auf anderen nie. Es scheint sich um eine Art Fehlfunktion des FS/Block-Layers/Controllers/Datenträgers zu handeln; viele Prozesse beginnen plötzlich, auf den Datenträger oder etwas anderes im Kernel zu warten, aber laut iotop/iostat tut der Datenträger nicht viel.
Gibt es eine Möglichkeit, den FS/Block Layer/Controller-Treiber des Linux-Kernels abzufragen, was genau sie mit dem Speicher machen und im Auftrag welches Prozesses? Standardtools wie iotop/iostat nennen mir nur die Namen aktiver I/O-Prozesse und die Festplattenpartitionsaktivität, aber nicht, welche Prozesse auf welche Festplattenpartition zugreifen und was genau sie dort machen.
Antwort1
In solchen Situationen finde ich, dass es hilfreich ist, die Anzahl der Verbindungen weiter oben im Stapel zu drosseln.
Wenn mehr als, sagen wir, 100aktivProzesse laufen, stolpern sie übereinander. Sie konkurrieren um Ressourcen (CPU usw.). Der Nettoeffekt ist, dassalleProzesse laufen langsamer, manchmal bis zu dem Punkt, an dem Sie das Gefühl haben, die einzige Lösung wäre ein Neustart des Servers.
Im Fall von MariaDB empfehle ich, das Slowlog einzuschalten, damit Sie die Abfrage identifizieren können, die den größten Einfluss auf das System hat. Beschleunigen Sie sie dann. Wenn Sie Hilfe benötigen, geben Sie die Abfrage, ihre Erläuterung und die Tabelle „Erstellen“ an. Mehr: http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog
Durch die Beschleunigung einiger Abfragen lässt sich wahrscheinlich die durchschnittliche Last und die E/A von 170 verringern und somit der Engpass beseitigen.