Ich kann nicht auf einen Remote-Server ssh, wenn der Speicher knapp wird, obwohl der Swap nicht vollständig genutzt wird

Ich habe einen Godaddy-Server, der in regelmäßigen Abständen nicht mehr reagiert. Es war schwierig, Fehler zu beheben, da ich nicht darauf eingehen kann, wenn es nicht mehr reagiert. Ich habe herausgefunden, was passiert ist, indem ich einen Cron-Job hinzugefügt habe, der alle 5 Minuten die Ausgabe von "top" an die Protokolldateien weiterleitet. Als ich es das nächste Mal aus- und wieder einschaltete, nachdem es nicht mehr reagierte, überprüfte ich diese Protokolle und stellte fest, dass der RAM voll war, aber der Tausch war größtenteils unbenutzt.

Ich arbeite daran, die RAM-Nutzung durch die beiden App-Server auf diesem Computer zu reduzieren (es stellte sich heraus, dass zu viele Verbindungen geöffnet wurden. Jeder verbrauchte 30 m, sodass nach dem Öffnen von 40 der Server keinen RAM mehr hat), aber was ich? Ich möchte wirklich gerne wissen, wie ich sicherstellen kann, dass ich in die Maschine ssh kann.

Wenn die Auslagerungsdatei nicht voll ist, würde ich denken, dass der Server genügend Speicherplatz hat, um zu antworten, selbst wenn dies langsam geschieht. Gibt es eine Möglichkeit, ein bisschen RAM zu reservieren, damit ich immer in die Maschine ssh kann?

Hier ist ein Beispiel dafür, wie es aussieht, wenn der Server normal läuft:

top - 15:13:21 up  3:12,  2 users,  load average: 0.15, 0.30, 0.33
Tasks: 127 total,   1 running, 126 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.4%us,  1.8%sy,  0.0%ni, 95.7%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   2064980k total,  1611252k used,   453728k free,    45852k buffers
Swap:  2096472k total,        0k used,  2096472k free,   790212k cached

Hier ist das letzte Top-Protokoll, das protokolliert wurde, bevor der Server nicht mehr ausgeführt wurde:

top - 14:45:08 up 15:20,  0 users,  load average: 0.27, 0.16, 0.10
Tasks: 141 total,   2 running, 139 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.7%us,  1.9%sy,  0.0%ni, 95.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2064980k total,  2007652k used,    57328k free,    60496k buffers
Swap:  2096472k total,      100k used,  2096372k free,   689584k cached

Beachten Sie, dass der Cron-Job, der die "Top" -Ausgabe protokolliert, auch nicht mehr ausgeführt wird, wenn der Server keinen RAM mehr hat, sodass der gesamte Server anscheinend nur zum Stillstand kommt.

Ich hatte ähnliche Probleme wie zuvor und sie können ein Ärgernis sein, um sie aufzuspüren. Da Sie viele Informationen zur Verfügung gestellt haben, muss ich einige Dinge darlegen, die überprüft werden müssen, und auch, wie sich mein Problem herausstellte.

Überprüfen Sie zunächst Ihre Protokolle. Vor allem in diesem Fall die Ausgabe von dmesg (dies ist der Kernel-Ringpuffer, in dem Protokolldaten ausgegeben werden). Dies wird regelmäßig in eine Datei in / var / log gelöscht, wobei dies genau von Ihrem Betriebssystem abhängt. Zum Beispiel hat Red Hat eine / var / log / dmesg-Datei. Sie suchen nach etwas, das ungewöhnlich aussieht, insbesondere in Bezug auf den OOM-KillerProzess. Dies beendet Programme, wenn der RAM voll wird, um den Server in Betrieb zu halten und zu reagieren. sshd sollte davon ausgenommen sein, dies ist jedoch distro-spezifisch in Bezug auf die Einstellung. Die moderne Form der Angabe einer OOM-Ausnahme besteht darin, sshd eine Bewertung zu geben, die dem Kernel angibt, wie wertvoll er für den gesamten Server ist (was ihn weit unten auf der Liste der Prozesse beenden sollte, die abgebrochen werden sollen, wenn eine kritische RAM-Situation auftritt). Ihre Distribution sollte dies richtig eingestellt haben.

Die andere zu überprüfende Sache ist, dass Ihr Server genug Entropie mit den folgenden hat:

cat /proc/sys/kernel/random/entropy_avail

Ein OK-Wert liegt über ca. 1000-1500. Unten und dir geht es zur Neige. Es geht wirklich nur bis zu ca. 4000-5000 auf meinen Maschinen (diese basieren auf meinen Beobachtungen meiner Server).

Ich hatte Probleme beim Anmelden bei Servern, bei denen die Entropie so niedrig war (und die Generierung langsam war), dass Anwendungen hängen blieben und darauf warteten, dass mehr Entropie verfügbar war. Es gibt einen berüchtigten Debian Exim-Fehler, der dies hervorgehoben hat. Exim verwendete GNU TLS unter Debian, das nur / dev / random verwendete und für jede Verbindung Entropiemassen verwendete. Siehe hier . Wenn die Entropie erschöpft war, hing Exim einfach. Dies würde auch dazu führen, dass andere Programme, die sich auf Entropie verlassen, ebenfalls Verbindungen ablehnen.

Da Sitzungsschlüssel in jeder Sitzung generiert werden, benötigt sshd eine gute Quelle für Zufallszahlen. Obwohl es / dev / urandom verwenden sollte, um Pseudozufallszahlen zu sammeln, wenn / dev / random blockiert, bin ich mir nicht sicher, ob sshd dies tun wird.

Dieses Problem kann auf virtuellen Systemen sehr schwerwiegend sein, da viele Zufallszahlenquellen nicht an die virtuelle Maschine übergeben werden. Die Hauptquelle für Entropie ist die Festplatten-E / A, diese wird jedoch normalerweise nicht an die VM übergeben. Es ist auch unwahrscheinlich, dass Hardware-Zufallszahlengeneratoren, die in den Chipsatz / die CPU der physischen Maschine eingebettet sind, an die virtuelle Maschine übergeben werden.

Dies ist ein ziemlich guter Bericht zu diesem Thema.

Ich laufe rngdim Hintergrund auf meinem Server, um / dev / random mit Daten aus / dev / urandom zu füttern.

rngd -r /dev/urandom -o /dev/random

Dies ist keine großartige Lösung, aber ein nützlicher Hack, um die Dinge zusammenzuhalten, während Sie nach besseren Zufallszahlenquellen suchen. Ich rngdmöchte Daten aus einer anderen Quelle einspeisen, hatte aber noch keine große Chance dazu.