Was kann dazu führen, dass ALLE Dienste auf einem Server ausfallen und dennoch auf Ping reagieren? und wie man es herausfindet

Es ist mir bereits zweimal innerhalb weniger Tage passiert, dass mein Server vollständig ausfällt, was bedeutet, dass http, ssh, ftp, dns, smtp im Grunde ALLE Dienste nicht mehr reagieren, als ob der Server ausgeschaltet worden wäre, außer dass er immer noch auf Ping reagiert , was mich am meisten verwirrt.

Ich habe einige PHP-Skripte, die in kurzen Bursts eine enorme Belastung (CPU und Speicher) des Servers verursachen, die von einer kleinen Gruppe von Benutzern verwendet wird, aber normalerweise "überlebt" der Server diese Bursts perfekt, und wenn er ausfällt fallen niemals mit solchen Nutzungsspitzen zusammen (ich sage nicht, dass es nicht in Beziehung gesetzt werden kann, aber es passiert nicht gleich danach).

Ich bitte Sie nicht, mir auf magische Weise die endgültige Ursache dieser Abstürze mitteilen zu können. Meine Frage lautet: Gibt es einen einzigen Prozess, dessen Tod dazu führen kann, dass alle diese Dienste gleichzeitig ausfallen? Das Lustige ist, dass alle Netzwerkdienste außer Ping ausfallen. Wenn der Server 100% der CPU durch einen Prozess verbraucht hätte, würde er auch nicht auf Ping reagieren. Wenn Apache (zum Beispiel) aufgrund eines kaputten PHP-Skripts abstürzt, wirkt sich dies nur auf http aus, nicht auf ssh und dns .... usw.

Mein Betriebssystem ist Cent OS 5.6

Welche Systemprotokolle sollte ich mir nach dem Neustart des Servers ansehen? / var / log / messages enthüllt nichts Verdächtiges.

centos service server-crashes

— matteo
quelle

Antworten:

( tl; dr immer noch auf Ping zu reagieren ist ein erwartetes Verhalten, überprüfen Sie Ihre Speichernutzung)

ICMP-Echoanforderungen (dh Ping) werden vom Kernel-Netzwerkstapel ohne weitere Abhängigkeit verarbeitet.

Der Kernel wird als "speicherresident" bezeichnet, was bedeutet, dass er immer im RAM gespeichert wird und nicht wie eine normale Anwendung auf die Festplatte übertragen werden kann.

Dies bedeutet, dass in Situationen, in denen Ihnen der physische Speicher ausgeht, Anwendungen auf die Festplatte ausgelagert werden, der Kernel jedoch dort bleibt, wo er sich befindet. Wenn sowohl der physische als auch der Swap-Speicher voll sind (und das System Ihre Programme nicht mehr lange verwalten kann), fällt der Computer um. Da sich jedoch a) der Kernel noch im Speicher befindet und b) er auf Ping-Anfragen ohne die Hilfe von irgendetwas anderem antworten kann, reagiert das System weiterhin auf Ping, obwohl alles tot ist.

In Bezug auf Ihr Problem würde ich Speicherprobleme stark vermuten. Installieren Sie "sysstat" und verwenden Sie den Befehl "sar", um ein Protokoll von Speicher / CPU / Laden / Io-Laden usw. anzuzeigen. Ich würde erwarten, dass zum Zeitpunkt des Absturzes sowohl 100% physisch als auch Swap verwendet werden.

Ich würde auch in Betracht ziehen, in dmesg oder / var / log / messages nach Anzeichen dafür zu suchen, dass der OOM-Killer (Out-of-Memory-Killer) aufgerufen wird. Dies ist das Notfallsystem des Kernels, das Prozesse beendet, wenn der Speicher erschöpft ist. Die Wirksamkeit hängt weitgehend davon ab, welche Prozesse abgetötet werden. Ein einzelner Prozess, der den Speicher verbraucht, wird effizient beendet und Speicher freigegeben. Eine Apache-basierte Website führt jedoch zu Ersatzprozessen, sobald ein untergeordneter Prozess beendet wird.

— Coops
quelle

+1 für OOM Killer

— HTTP500

Vielen Dank, ich bin mir fast sicher, dass dies das Problem ist, da sowohl der RAM als auch der Swap vor dem Serverausfall voll waren. (Ich kann auf den Statistiken von ovh's Manager sehen). Und es sind wahrscheinlich einige meiner verrückten PHP-Skripte, die viel Speicher benötigen. Es verwirrt mich jedoch aus mehreren Gründen. (1) sieht so aus, als ob der von PHP aufgefressene Speicher danach nicht freigegeben wird, aber das würde keinen Sinn ergeben; (2) Auf jeden Fall würde ich nicht erwarten, dass ein richtiges Betriebssystem vollständig

— ausfällt,

Weigern Sie sich, Programmen, die danach fragen, Speicher zuzuweisen, wenn nicht genügend RAM vorhanden ist, damit das System ordnungsgemäß funktioniert ... Ich meine, ein fehlerhafter oder sogar bösartiger Programm sollte niemals in der Lage sein, das gesamte System zu zerstören ...

— matteo

@matteo Linux hat das, was es "Overcommit" nennt: Nur weil Sie malloc()1 GB RAM haben, heißt das nicht, dass Sie es verwenden werden. Der Speichermanager verfolgt also, wie viel Speicher Ihr Programm für vorhanden hält und wie viel Speicher der Programm hat tatsächlich verwendet, und es funktioniert tatsächlich die meiste Zeit gut. Zumindest bis mehr als ein Programm tatsächlich alle 1 GB nutzen möchte, die es zu haben glaubt.

— DerfK

@matteo Ich sehe keinen Hinweis darauf, dass dies ein OOM-Problem ist. Normalerweise wählt der OOM-Killer bestimmte Prozesse aus, die bestimmte Kriterien erfüllen, aber er würde einen Daemon wie ssh nicht immer töten. Dies ist definitiv auf der E / A-Seite. Sie haben Ihre Hardware-Situation / Spezifikationen nicht so erklärt, wie ich es in meiner Antwort angefordert habe.

— ewwhite

Normalerweise handelt es sich um ein Problem mit dem E / A- oder Festplattensubsystem. Dies ist häufig mit einem extrem hohen Systemlastdurchschnitt verbunden. Zum Beispiel reagierte das in der folgenden Grafik dargestellte System nicht mehr (war jedoch pingfähig), als ein Skript schief lief, eine Reihe von Dateien sperrte und die Last auf einem 4-CPU-System auf 36 ... anstieg.

Geben Sie hier die Bildbeschreibung ein

Die Dienste, die im RAM ausgeführt werden und keinen Festplattenzugriff erfordern, werden weiterhin ausgeführt ... Somit ist der Netzwerkstapel (Ping) aktiv, aber die anderen Dienste werden angehalten, wenn Festplattenzugriff erforderlich ist ... SSH, wenn auf einen Schlüssel verwiesen wird oder Passwortsuche erforderlich. SMTP wird normalerweise heruntergefahren, wenn der Lastdurchschnitt 30 oder so erreicht ...

Wenn sich das System in diesem Zustand befindet, versuchen Sie es mit einer Fernbedienung nmapanhand der IP- Adresse des Servers, um festzustellen, was aktiv ist.

Ihre Protokollierung funktioniert wahrscheinlich nicht, wenn es sich um ein Festplatten- oder Speicherproblem handelt ...

Können Sie das Hardware-Setup beschreiben? Ist das eine virtuelle Maschine? Wie ist das Speicherlayout?

Sie möchten nicht nur protokollieren, sondern auch die Systemleistung grafisch darstellen und verstehen, wann dies geschieht. Überprüfen Sie, ob dies mit einer bestimmten Aktivität korreliert.

— ewwhite
quelle

Angenommen, dies ist das Problem. Gibt es eine Möglichkeit, SSH anzuweisen, die Kennwörter im Speicher zu behalten? Selbst wenn sich der Server in diesem Zustand befindet, kann ich mich möglicherweise zumindest über ssh anmelden und einige Befehle ausführen, um zu sehen Was ist los?

— Matto

Wenn es sich um E / A handelt, müssen Sie dem Problem auf den Grund gehen. Wenn es sich um ein Zeitlimit für ein Festplattenarray oder eine Treiberinteraktion handelt, unterscheidet sich dies von einem Skript, das schlecht ausgeführt wird, oder von einem Problem mit Ressourcenkonflikten.

— ewwhite