Lösung für 700 % CPU-Auslastung eines Linux-Prozesses, der nicht beendet werden kann

1. Problemerkennung

[root@zwlbs3 ~]# nach oben

i. Ich stellte fest, dass die CPU-Auslastung eines Prozesses 700 % betrug und COMMAND aus einigen zufälligen Zeichenfolgen bestand. Ich war fertig! Das Erste, woran ich dachte, war, ihn zu beenden.

[root@zwlbs3 ~]# kill -9 "PID"

ii. Es wurde jedoch festgestellt, dass der Prozess nach seiner Beendigung eine Zeit lang ruhig war und erneut startete.

Hinweis: Das alte Image wird wiederverwendet und PID und COMMAND haben sich geändert.

2. Detaillierte Informationen zum Prozess anzeigen

[root@zwlbs3 ~]# cd /proc/748/
[root@zwlbs3 748]# ls -ial

# „748“ ist die PID des Prozesses. Sie können sie anhand Ihrer PID überprüfen.

Wie in der Abbildung gezeigt:

Es wurde festgestellt, dass sich der Prozess im Verzeichnis /dev/shm befindet. Was ist /dev/shm?

Nehmen wir einen Absatz aus dem Internet und erklären /dev/shm

1) Zunächst einmal können wir sehen, dass /dev/shm eine Gerätedatei ist. Wir können uns /dev/shm als den Eingang zum Systemspeicher vorstellen. Wir können es uns als physisches Speichergerät vorstellen, ein temporäres Dateisystem. Sie können dieses Gerät verwenden, um Dateien aus dem Speicher zu lesen und in diesen zu schreiben, um bestimmte I/O-Operationen zu beschleunigen, wie z. B. häufiges Öffnen, Schreiben und Lesen einer großen Datei.

2) Es wird gesagt, dass Oracle /dev/shm verwendet (shitou hat Oracle noch nie verwendet), und der Mount-Befehl kann verwendet werden, um die aktuell unter /dev/shm gemounteten Dateisysteme aufzulisten.

3) Da es sich um ein speicherbasiertes Dateisystem handelt, sind die Dateien unter /dev/shm nach dem Neustart des Systems nicht mehr vorhanden. Die Standardpartitionsgröße /dev/shm unter Linux (CentOS) beträgt 50 % des physischen Systemspeichers, obwohl die Verwendung von /dev/shm für Dateivorgänge viel effizienter ist. Allerdings wird es derzeit von wenigen Softwaredistributionen verwendet (außer dem oben erwähnten Oracle). Sie können ls /dev/shm verwenden, um zu prüfen, ob sich darunter eine Datei befindet. Wenn nicht, bedeutet dies, dass das aktuelle System das Gerät nicht verwendet.

Überprüfen Sie, ob sich im Verzeichnis /dev/shm zugehörige Dateien befinden

[root@zwlbs3 ~]# ls -a /dev/shm/
. ..

# Es gibt keine zugehörige Datei, was seltsam ist.

• Es sind keine mit Crontab verbundenen geplanten Aufgaben vorhanden.
• Der „Which“-Befehl hat ebenfalls keine zugehörigen Dateien gefunden.
• Auch die Überprüfung des Systemprotokolls ist normal, was sehr merkwürdig ist.
• Es wurden fast keine mit diesem Vorgang in Zusammenhang stehenden Dateien gefunden.

3. Lösung

i. Die Thread-Belegungsanalyse innerhalb eines Prozesses anzeigen

[root@zwlbs3 ~]# top -H -p "PID" 

ii. Es gibt so viele verwandte Prozesse, töte sie alle

iii. Überprüfen Sie nach ein paar Minuten erneut, ob die Systemlast wieder normal ist.

Ich dachte, das Problem wäre gelöst, aber als ich ein paar Stunden später nachschaute, tauchte es wieder auf. Verdammt.

Da es in der Produktionsumgebung nicht praktisch ist, den Server neu zu starten, blieb mir nichts anderes übrig, als die Neustartmethode auszuprobieren.

4. Starten Sie Dafa neu

Eine Stunde nach dem Neustart des Servers habe ich noch einmal nachgesehen und alles war wieder im Normalzustand. Der Neustart funktioniert immer noch einwandfrei.

Was macht dieses Schadprogramm? Warum nur CPU-Ressourcen verbrauchen? Da keine relevanten Dateiinformationen gefunden wurden, ist der Grund derzeit nicht klar.

Wenn es jemand weiß, sagen Sie es mir bitte, vielen Dank!

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.