Ich renneDebian GNU/Linux 5.0und ich erlebe zeitweise Out_of_Memory-Fehler, die vom Kernel kommen. Der Server reagiert nur noch auf Pings und ich muss den Server neu starten.
# uname -a
Linux xxx 2.6.18-164.9.1.el5xen #1 SMP Tue Dec 15 21:31:37 EST 2009 x86_64
GNU/Linux
Dies scheint der wichtige Teil von /var/log/messages zu sein
Dec 28 20:16:25 slarti kernel: Call Trace:
Dec 28 20:16:25 slarti kernel: [<ffffffff802bedff>] out_of_memory+0x8b/0x203
Dec 28 20:16:25 slarti kernel: [<ffffffff8020f825>] __alloc_pages+0x245/0x2ce
Dec 28 20:16:25 slarti kernel: [<ffffffff8021377f>] __do_page_cache_readahead+0xc6/0x1ab
Dec 28 20:16:25 slarti kernel: [<ffffffff80214015>] filemap_nopage+0x14c/0x360
Dec 28 20:16:25 slarti kernel: [<ffffffff80208ebc>] __handle_mm_fault+0x443/0x1337
Dec 28 20:16:25 slarti kernel: [<ffffffff8026766a>] do_page_fault+0xf7b/0x12e0
Dec 28 20:16:25 slarti kernel: [<ffffffff8026ef17>] monotonic_clock+0x35/0x7b
Dec 28 20:16:25 slarti kernel: [<ffffffff80262da3>] thread_return+0x6c/0x113
Dec 28 20:16:25 slarti kernel: [<ffffffff8021afef>] remove_vma+0x4c/0x53
Dec 28 20:16:25 slarti kernel: [<ffffffff80264901>] _spin_lock_irqsave+0x9/0x14
Dec 28 20:16:25 slarti kernel: [<ffffffff8026082b>] error_exit+0x0/0x6e
Vollständiger Ausschnitt hier:http://pastebin.com/a7eWf7VZ
Ich dachte, dass dem Server vielleicht tatsächlich der Speicher ausgeht (er hat 1 GB physischen Speicher), aber mein Cacti-Speicherdiagramm sieht für mich in Ordnung aus ...
Ein Freund korrigierte mich hier; er bemerkte, dass die Grafik eigentlich invertiert ist, da das Lila anzeigtSpeicher frei(kein Speicher verwendet, wie der Titel vermuten lässt).
Aber seltsamerweise schießt die Lastkurve kurz vor dem Absturz des Kernels durch die Decke:
In welchen Protokollen kann ich für weitere Informationen nachsehen?
Aktualisieren:
Vielleicht bemerkenswert - die Diagramme für den CPU-Prozentsatz und den Netzwerkverkehr waren zum Zeitpunkt des Absturzes beide normal. Die einzige Anomalie war das Diagramm für die durchschnittliche Auslastung.
Aktualisierung 2:
Ich glaube, das passierte, als ich Passenger/Ruby bereitgestellt habe. Dabei tophabe ich gesehen, dass Ruby den größten Teil des Speichers und ziemlich viel CPU-Leistung nutzt:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5189 www-data 18 0 255m 124m 3388 S 0 12.1 12:46.59 ruby1.8
14087 www-data 16 0 241m 117m 2328 S 21 11.4 3:41.04 ruby1.8
15883 www-data 16 0 239m 115m 2328 S 0 11.3 1:35.61 ruby1.8
Antwort1
Überprüfen Sie die Protokollnachrichten auf Hinweise zum Kernel-Out-of-Memory-Killer oder OOM killeddie Ausgabe von dmesg. Dies kann Hinweise darauf geben, welche Prozesse das Ziel des OOM-Killers waren. Sehen Sie sich auch Folgendes an:
http://lwn.net/Articles/317814/
Und
http://linux-mm.org/OOM_Killer
Was macht dieses System? Erschöpfen Sie gleichzeitig den Swap? Basierend auf Ihrem externen Link, der den Absturz beschreibt, sieht es so aus, als ob rsyslogd das Problem ist. Dies könnte eine Situation sein, in der ein regelmäßiger Neustart der App nützlich wäre.
Antwort2
2.6.18 ist ein sehr alter Kernel. Ich bin auf Probleme gestoßen, bei denen bestimmte Bedingungen Endlosschleifen im Kernel auslösen können, was alles von Speichererschöpfung bis hin zur vollständigen Ausschöpfung der E/A-Bandbreite zur Folge hat, wenn dieselben Daten in einer Endlosschleife auf die Festplatte geschrieben werden (was zwar Lastspitzen, aber eine normale CPU-Auslastung verursacht).
Diese Fehler werden normalerweise bald nach ihrer Meldung behoben, sodass sich ein Kernel-Upgrade problemlos durchführen lässt. Außerdem erhält man bei einem Kernel-Upgrade einige kostenlose Sicherheitsfixes :-)
Antwort3
Vergessen Sie außerdem nicht, dass Cacti und ähnliche Programme Diagramme mit einer bestimmten Auflösung erstellen (collectd hat die Standardauflösung 5 s, Cacti, glaube ich, 30 s), sodass ein Zeitraum von 30–60 Sekunden nicht unbedingt in Ihren Diagrammen angezeigt wird. Wenn das System völlig überlastet ist, wirkt sich dies auch auf den Daemon zur Datenerfassung aus.
Möglicherweise finden Sie weitere nützliche Informationen in Ihren Protokolldateien, sei es in den allgemeinen Dateien /var/log/messages oder in den dienstspezifischen Dateien /var/log/apache2/error.log.
Wenn das nicht möglich ist, empfehle ich Ihnen, Ihre Dienste durchzugehen (in Ihrem Protokollauszug oben ist mir Apache2 aufgefallen) und zu überprüfen, ob sie eine Speichererschöpfung auf Ihrem Server verursachen können. (Beispiel: Die Standardkonfiguration von Apache mit mod_prefork und PHP sollte in der Lage sein, Ihr System zum Stillstand zu bringen.)