Lassen Sie mich gehen, die CPU des Linux-Systems ist zu 100 % ausgelastet!-LINUX-php.cn

Gestern Nachmittag erhielt ich plötzlich eine E-Mail-Benachrichtigung von der Betriebs- und Wartungsabteilung, die zeigte, dass die CPU-Auslastung des Datenplattformservers bis zu 98,94 % betrug. In jüngster Zeit liegt dieser Auslastungsgrad weiterhin über 70 %. Auf den ersten Blick scheint es, dass die Hardware-Ressourcen einen Engpass erreicht haben und erweitert werden müssen. Aber nachdem ich sorgfältig darüber nachgedacht hatte, stellte ich fest, dass unser Geschäftssystem keine hochgradig gleichzeitige oder CPU-intensive Anwendung ist. Diese Auslastung ist zu hoch und der Hardware-Engpass kann nicht so schnell erreicht werden. Irgendwo muss ein Problem mit der Geschäftscodelogik vorliegen.

2. Ideen zur Fehlerbehebung

2.1 Prozess-PID mit hoher Auslastung ermitteln

Melden Sie sich zuerst beim Server an und verwenden Sie den oberen Befehl, um die spezifische Situation des Servers zu bestätigen, und analysieren und beurteilen Sie dann anhand der spezifischen Situation.

Durch Beobachtung des Lastdurchschnitts und des Lastbewertungsstandards (8 Kerne) kann bestätigt werden, dass der Server eine hohe Last hat

Wenn wir die Ressourcennutzung jedes Prozesses beobachten, können wir sehen, dass der Prozess mit der Prozess-ID 682 ein höheres CPU-Verhältnis aufweist

2.2 Lokalisieren Sie bestimmte ungewöhnliche Geschäfte

Hier können wir den Befehl pwdx verwenden, um den Geschäftsprozesspfad basierend auf der PID zu finden und dann die verantwortliche Person und das Projekt zu lokalisieren:

Daraus lässt sich schließen, dass dieser Prozess dem Webservice der Datenplattform entspricht.

2.3 Suchen Sie den abnormalen Thread und bestimmte Codezeilen

Die traditionelle Lösung besteht im Allgemeinen aus 4 Schritten:

1. Top-Reihenfolge mit P: 1040 // Zuerst nach Prozesslast sortieren, um maxLoad(pid) zu finden

2. top -Hp-Prozess-PID: 1073 // Finden Sie die relevante Last-Thread-PID

3. printf „0x%x“ Thread-PID: 0x431 // Konvertieren Sie die Thread-PID in Hexadezimalzahl, um die spätere Suche im Jstack-Protokoll vorzubereiten

4. jstack-Prozess-PID |. vim +/hex Thread-PID – // Zum Beispiel: jstack 1040|vim +/0x431 –

Aber für die Online-Problemlokalisierung zählt jede Sekunde, und die oben genannten 4 Schritte sind immer noch zu umständlich und zeitaufwändig. Oldratlee, der Taobao zuvor eingeführt hat, hat den obigen Prozess in einem Tool zusammengefasst: show-busy-java-threads.sh. Sie können diese Art von Problem ganz einfach online finden:

Daraus kann geschlossen werden, dass die Ausführungs-CPU einer Zeitwerkzeugmethode im System relativ hoch ist. Überprüfen Sie nach dem Auffinden der spezifischen Methode, ob Leistungsprobleme in der Codelogik vorliegen.

※ Wenn das Online-Problem dringender ist, können Sie 2.1 und 2.2 weglassen und 2.3 direkt ausführen. Die Analyse erfolgt hier aus mehreren Blickwinkeln, um Ihnen eine vollständige Analyseidee zu präsentieren.

3. Ursachenanalyse

Nach der vorherigen Analyse und Fehlerbehebung haben wir schließlich ein Problem mit den Zeittools gefunden, das zu einer übermäßigen Serverlast und CPU-Auslastung führte.

Ausnahmemethodenlogik: besteht darin, den Zeitstempel in das entsprechende spezifische Datums- und Uhrzeitformat umzuwandeln
Aufruf der oberen Ebene: Berechnen Sie alle Sekunden vom frühen Morgen bis zur aktuellen Zeit, konvertieren Sie sie in das entsprechende Format und fügen Sie sie in den Satz ein, um das Ergebnis zurückzugeben
Logikschicht: Entspricht der Abfragelogik des Echtzeitberichts der Datenplattform. Der Echtzeitbericht erfolgt in einem festen Zeitintervall und es gibt mehrere (n) Methodenaufrufe in einer Abfrage.

Dann kann gefolgert werden, dass, wenn die aktuelle Zeit 10 Uhr morgens ist, die Anzahl der Berechnungen für eine Abfrage 106060n Mal = 36.000n Berechnungen beträgt und dass die Anzahl mit zunehmender Zeit zunimmt Anzahl einzelner Abfragen nähert sich Mitternacht und nimmt linear zu. Da eine große Anzahl von Abfrageanforderungen von Modulen wie Echtzeitabfragen und Echtzeitalarmen den mehrmaligen Aufruf dieser Methode erfordern, werden große Mengen an CPU-Ressourcen belegt und verschwendet.

4. Lösung

Nachdem das Problem lokalisiert wurde, besteht die erste Überlegung darin, die Anzahl der Berechnungen zu reduzieren und die Ausnahmemethode zu optimieren. Nach einer Untersuchung wurde festgestellt, dass bei Verwendung auf der Logikebene nicht der Inhalt der von dieser Methode zurückgegebenen Mengensammlung verwendet wurde, sondern einfach der Größenwert der Menge verwendet wurde. Verwenden Sie nach Bestätigung der Logik eine neue Methode, um die Berechnung zu vereinfachen (aktuelle Sekunden - Sekunden am frühen Morgen des Tages), ersetzen Sie die aufgerufene Methode und lösen Sie das Problem übermäßiger Berechnungen. Nachdem wir online gegangen waren, beobachteten wir, dass die Serverlast und die CPU-Auslastung im Vergleich zum ungewöhnlichen Zeitraum um das 30-fache zurückgingen. Zu diesem Zeitpunkt wurde das Problem behoben.

![Gestern Nachmittag erhielt ich plötzlich eine E-Mail-Benachrichtigung von der Betriebs- und Wartungsabteilung, aus der hervorging, dass die CPU-Auslastung des Datenplattformservers bis zu 98,94 % betrug. In jüngster Zeit liegt dieser Auslastungsgrad weiterhin über 70 %. Auf den ersten Blick scheint es, dass die Hardware-Ressourcen einen Engpass erreicht haben und erweitert werden müssen. Aber nachdem ich sorgfältig darüber nachgedacht hatte, stellte ich fest, dass unser Geschäftssystem keine hochgradig gleichzeitige oder CPU-intensive Anwendung ist. Diese Auslastung ist zu hoch und der Hardware-Engpass kann nicht so schnell erreicht werden. Irgendwo muss ein Problem mit der Geschäftscodelogik vorliegen.