Bei mir ist es innerhalb weniger Tage bereits zweimal passiert, dass mein Server komplett ausgefallen ist. Das heißt, http, ssh, ftp, dns, smtp, im Grunde ALLE Dienste reagierten nicht mehr, als ob der Server abgeschaltet worden wäre. Außer, dass er noch auf Ping reagiert, was mich am meisten ärgert.
Ich habe einige PHP-Skripte, die in kurzen Schüben eine enorme Belastung (CPU und Speicher) auf dem Server verursachen und von einer kleinen Gruppe von Benutzern verwendet werden. Normalerweise „überlebt“ der Server diese Schübe jedoch problemlos, und wenn er ausfällt, geschieht dies nie zeitgleich mit solchen Nutzungsspitzen (ich sage nicht, dass es nicht damit zusammenhängen kann, aber es geschieht nicht direkt danach).
Ich verlange nicht von Ihnen, dass Sie mir auf magische Weise die eigentliche Ursache dieser Abstürze nennen können. Meine Frage lautet: Gibt es einen einzelnen Prozess, dessen Absturz dazu führen kann, dass alle diese Dienste gleichzeitig ausfallen? Das Lustige ist, dass alle Netzwerkdienste ausfallen, außer Ping. Wenn der Server 100 % der CPU-Leistung durch einen Prozess beansprucht hätte, würde er auch nicht auf Ping reagieren. Wenn Apache beispielsweise aufgrund eines defekten PHP-Skripts abstürzt, würde dies nur HTTP betreffen, nicht SSH und DNS usw.
Mein Betriebssystem ist Cent OS 5.6
Am wichtigsten ist, welche Systemprotokolle ich mir nach dem Hard-Reboot des Servers ansehen sollte. /var/log/messages zeigt nichts Verdächtiges.
Antwort1
(tl;drimmer noch auf Ping zu reagieren ist ein erwartetes Verhalten, überprüfen Sie Ihre Speichernutzung)
ICMP-Echoanforderungen (z. B. Ping) werden vom Netzwerkstapel im Kernel verarbeitet, ohne weitere Abhängigkeiten.
Der Kernel ist bekannt als „speicherresident“, was bedeutet, dass er immer im RAM gespeichert wird und nicht wie eine normale Anwendung auf die Festplatte ausgelagert werden kann.
Dies bedeutet, dass in Situationen, in denen der physische Speicher voll ist, Anwendungen auf die Festplatte ausgelagert werden, der Kernel aber dort bleibt, wo er ist. Wenn sowohl der physische als auch der Swap-Speicher voll sind (und das System Ihre Programme nicht mehr verwalten kann), stürzt die Maschine ab. Da jedochA)der Kernel ist noch im Speicher undB)Es kann ohne die Hilfe anderer auf Ping-Anfragen antworten. Das System antwortet weiterhin auf Pings, auch wenn alles tot ist.
In Bezug auf Ihr Problem vermute ich stark Speicherprobleme. Installieren Sie „sysstat“ und verwenden Sie den Befehl „sar“, um ein Protokoll der Speicher-/CPU-/Last-/E/A-Last usw. anzuzeigen. Ich würde erwarten, dass Sie zum Zeitpunkt des Absturzes sowohl 100 % physische als auch Swap-Auslastung sehen würden.
Ich würde auch in Betracht ziehen,dmesgoder/var/log/Nachrichtenauf Anzeichen für den Aufruf des OOM-Killers (Out-of-Memory-Killer). Dies ist das Notfallsystem des Kernels, das Prozesse beendet, wenn der Speicher erschöpft ist. Seine Wirksamkeit hängt weitgehend davon ab, welche Prozesse beendet werden. Ein einzelner Prozess, der den Speicher verbraucht, wird effizient beendet und Speicher freigegeben, eine Apache-basierte Website erzeugt jedoch Ersatzprozesse, sobald ein untergeordneter Prozess beendet wird.
Antwort2
Normalerweise handelt es sich um ein E/A- oder Festplattensubsystemproblem. Oft geht dies mit einer extrem hohen durchschnittlichen Systemlast einher. Beispielsweise reagierte das in der folgenden Grafik dargestellte System nicht mehr (war aber pingbar), als ein Skript schief lief, eine Reihe von Dateien sperrte und die Last auf 36 stieg... auf einem 4-CPU-System.
Die Dienste, die im RAM laufen und keinen Festplattenzugriff benötigen, laufen weiter... Der Netzwerkstapel (Ping) ist also aktiv, aber die anderen Dienste geraten ins Stocken, wenn Festplattenzugriff erforderlich ist... SSH, wenn auf einen Schlüssel verwiesen wird oder eine Kennwortsuche erforderlich ist. SMTP neigt dazu, heruntergefahren zu werden, wenn die durchschnittliche Auslastung 30 oder so erreicht...
Wenn sich das System in diesem Zustand befindet, versuchen Sie einen Remote- nmapZugriff auf die IP des Servers, um zu sehen, was los ist.
Ihre Protokollierung funktioniert wahrscheinlich nicht, wenn es sich um ein Festplatten- oder Speicherproblem handelt …
Können Sie den Hardware-Aufbau beschreiben? Handelt es sich um eine virtuelle Maschine? Wie ist das Speicherlayout?
Mehr als nur Protokollierung möchten Sie sehen, ob Sie die Systemleistung grafisch darstellen und erkennen können, wann dies geschieht. Prüfen Sie, ob dies mit einer bestimmten Aktivität korreliert.