Aufgrund von Tests auf unserer Serverfarm, kann man nur vor dem Einsatz von Kernel 4.8.13 warnen. Lediglich wenig genutzte Rechner kommen dafür in Frage. Die Testserver unserer Farm fielen nach wenigen Stunden durch wahre OOM-Killer Amokläufe aus, obwohl nicht ein BIT Swap Speicher genutzt wurde, oder der reale Hauptspeicher auch nur annähernd erschöpft gewesen wäre.
Die Ursache kann daher nur Speicherfragmentierung sein. Es gibt zwar in Summe genug Hauptspeicher, aber nicht genug zusammenhängenden Speicher um Anfragen zu befriedigen.
Kernel 4.9+ soll Abhilfe schaffen. Glücklicherweise wurde der grade freigegeben.
Es ist mal wieder soweit: „mir ham a problem“ (cnr)
Leider ist es kein witziges Problem, deswegen ist der Gag oben auch echt unangebracht, aber wie das so ist, Menschen versuchen ernste Probleme mit Humor zu vereinfachen. Vermutlich geben die „Forscher“ Ihren tollen Sicherheitslücken deswegen Namen wie „Dirty COW“ oder „Poodle“.
Out-Of-Memory
Wie Ihr schon im Beitrag über das Abschalten der RAM Disk für /tmp lesen konntet, sind OOM Probleme grade meine Hauptsorge #1. Seit Kernel 4.7.2 häufen sich die Meldungen, daß Systeme mit exorbitant viel RAM keinen Speicher mehr haben. Das Kürzel ist OOM was für Out-Of-Memory steht und die dafür zuständige Kernelkomponente ist, na wer räts? Der OOM-Killer 🙂
Mein aktuelles Sorgenkind hat 10 GB RAM und benutzt davon im Normalfall 1.5 GB, der Rest geht für Caches drauf, was die Performance des Systems erhöht, aber auch die Ursache sein könnte, denn mit 8.5 GB freiem Speicher, kann man wohl kaum im normalen Betrieb einen OOM produzieren, wenn man einen Webserver betreibt. Es gibt nur einen Grund wieso ein OOM passieren kann : Die Anforderung an RAM ist größer als der freie Speicher + Swap .
Ursachenforschung
Bei der Analyse des Problems fiel auf, daß SWAP überhaupt nicht benutzt wird, wenn es zum OOM kommt, was nur bedeuten kann, der Algorithmus des OOM-Mechanismuses im Kernel hat einen Bug. Wie es der Zufall so will, hatte das 16 GB Laptop von Linus Torvalds im September einen OOM Vorfall, welcher Mr. Linux dazu gebracht hat, eine Email dazu rumzuschicken. In der Email findet sich der Hinweis, daß Linus vermutet, ein 1 KB Ramrequest hätte seine 16 GB Maschine zum OOM gezwungen. Ferner entnehmen wir der Email, daß im Kernel 4.7 ein neuer Patch für OOM Situationen implementiert wurde:
"I'm afraid that the oom situation is still not fixed, and the "let's
die quickly" patches are still a nasty regression." (Linus Torvalds, 18.9.2016)
Nun passiert das zum Glück nicht nur mir, weil mir ja sonst wieder Paranoia und „unsupported systemconfigurations“ vorgeworfen würden 😉 . Einer der Bugreporter bei Redhat berichtet dann auch, daß er das verhindern konnte, indem er einen Cron eingerichtet hat, der alle 2 Stunden die Caches auf die Platte geflusht hat.
Ob Cacheflushen hilft ?
sync && echo 1 > /proc/sys/vm/drop_caches
Natürlich werde ich das ausprobieren, denn wenn das funktioniert, ist die Ursache sehr wahrscheinlich Memory Fragmentation caused by Cacheallocations. Das würde nämlich passen. Der Server hat immer dann Probleme, wenn viel Cachespeicher in Gebrauch ist. Caches bauen sich nicht so auf, daß der Kernel sieht „oh jetzt habe ich 8 GB frei, laß mal 8 GB am Stück belegen, ich gebs frei, wenn einer was will“ sondern das wird Portionsweise gemacht, mal hier 100 MB, da mal 200 MB, wie die Aktivitäten des Systems das eben grade brauchen. d.b. Selbst wenn keine neuen Prozesse über die Zeit dazu kämen und Speicher bräuchten, würde der freie Speicher in Cacheblöcke aufgeteilt, die wiederum nach Benutzung ggf. freigegeben und neu alloziert werden.
1 Woche Memorystatistiken und solange die Caches klein waren, gab es keine OOMs.
Dies ist ein hochdynamischer Vorgang, den man sich als Laie schwer vorstellen kann. Selbst Cachblöcke werden intern über einen Poolingalgorithmus verwaltet, d.b. der Kernel nimmt mehr freien Speicher als er grade braucht in der Annahme, daß der in Zukunft schon belegt werden wird. Daher gibt es im MemoryPool Funktionen Speicher innerhalb eines Pools zu allozieren oder freizugeben : Speicherverwaltung in Speicherblöcken.
Memorypools
Das ist beileibe keine neue Erfindung, das hatte schon ein Amiga 1988 zu bieten. So ein MemoryPool ist sogar extrem sinnvoll in dynamischen Situationen, weil man damit Verwaltungslasten vom System auf einen Prozess umlagert (Stichwort Selbstorganisation). Der Kernel muß sich um weniger Speicherbereiche kümmern, was den Aufwand minimiert und die Speicherverwaltungsketten für Speicherblöcke minimiert. Das schafft quasi „Übersicht“ und ist für alle schneller, weil er bessere Entscheidungen treffen kann.
OOM im Logfile
Damit Ihr einen OOM erkennen könnt, so sieht der im Logfile aus :
Wenn man sich den Thread auf der Kernel-ML weiter durchliest, kommt raus, daß erst mit Kernel 4.9 mit einer Verbesserung zu rechnen ist. Ab 4.9 wird ein anderer Algorithmus benutzt, der „härter“ versuchen soll, den OOM zu verhindern. Man wird sehen.
Update 18:00 Uhr :
Das Wegflushen der Filecache hat nichts gebracht. Aber Kernel 4.6.8 sollte noch keine oom’s produzieren. Das beinhaltet aber wieder eine Angriffsfläche für den Dirty COW Exploit.
