Playframework: Play2 OOM gibt kein .hprof-Log aus

OOM Killer ist eine Schlampe. Es hat nichts mit dem Java-Heap zu tun, daher hilft es nicht, einen Heap-Dump auf oome zu setzen. Wenn Sie Linux nach Arbeitsspeicher fragen, erhalten Sie im Grunde einen Hinweis, auch wenn es nicht so viel Arbeitsspeicher zur Verfügung hat. Es weist den Speicher erst dann zu, wenn Sie ihn verwenden. Dies ist, was es tun soll, beispielsweise eine Stapelgröße von 2 Megabyte pro Thread und 10000 Threads zu haben, die theoretisch 20 GB Speicher benötigen, aber Sie haben diesen Speicher nicht auf dem Computer. Die meisten Threads verwenden nicht annähernd 2 MB Stack, daher wird nie der Speicher zugewiesen, den sie nicht verwenden.

Aber was passiert dann, wenn alles beginnt, den zugewiesenen Speicher zu verwenden, aber kein Speicher verfügbar ist, um träge zugewiesen zu werden? Geben Sie OOM-Killer ein. Linux wählt einen Prozess zum Beenden aus, der nach dem Beenden genügend Speicher zum Zuweisen freigibt. Da Java-Prozesse viel Speicher beanspruchen, wählt es sehr oft einen Java-Prozess aus. Es sendet ein SIGKILL, das bedeutet kein Core-Dump und keine Chance für die JVM, irgendetwas zu tun, um zu versuchen, zu bereinigen oder ordnungsgemäß herunterzufahren.

Dies funktioniert gut für Dinge wie PHP-Apps, bei denen jede Anfrage einem Prozess entspricht. Töte den größten Apache-Arbeiter. Problem gelöst. Für Java-Apps ist dies die dümmste Funktion aller Zeiten.

Was können Sie dagegen tun? Nicht viel, es gibt einige Dinge, die Sie im Linux-Kernel einstellen können, aber Sie können ihn nicht ganz ausschalten, und alles, was ich darüber gelesen habe, klingt, als wäre es einfach nicht praktikabel, Linux dazu zu bringen, dies nicht zu tun.

Hier ist, was Sie tun müssen:

• 512 MB sind zu viel, eine Mikroinstanz hat nur ungefähr 600 MB, das Betriebssystem benötigt etwas und die JVM verwendet mehr als nur ihre Heaps. Stellen Sie Ihre Heap-Größe auf 256 MB ein. Dies sollte für eine kleine Play-App in Ordnung sein.
• Stellen Sie sicher, dass sich auf dem Server nichts anderes befindet, das viel Speicher verbrauchen könnte. Wenn ja, beheben Sie es. Wenn Sie Apache oder ähnliches ausführen, ist dies ein guter Ort, um mit der Suche zu beginnen.
• Ich bin mir nicht sicher, ob es möglich ist, einer EC2-Mikroinstanz eine Auslagerungsdatei hinzuzufügen. Wenn dies der Fall ist, erhalten Sie einen Puffer, bevor der OOM-Killer zuschlägt.

Wie auch immer, das hat nichts mit Play zu tun, also schließe ich.

Mir ist gerade aufgefallen, dass die Play APP seit einiger Zeit ausgefallen ist, aber ich kann keine Informationen finden.
Dann ist mir aufgefallen, dass der Linux OOM Killer auch.
danke @jroper für diese Informationen.
Ich denke, diese Informationen sollten im Play-Benutzerhandbuch veröffentlicht werden

Vielen Dank für alle Details in Ihrer Antwort. Dies wird definitiv dazu beitragen, ein weiteres OOM zu verhindern, aber meine Besorgnis, dass etwas in meinem Code zu viel Heap-Speicherplatz benötigt, wird nicht ausgeräumt. Ich dachte, eine .hprof-Datei würde ausgegeben, wenn ich den Parameter -J-XX:+HeapDumpOnOutOfMemoryError setze. Die .hprof-Datei wäre wirklich hilfreich, um alle Threads und ihre Stack-Traces zum Zeitpunkt des oom-Killers zu untersuchen.

Wie ich bereits sagte, ist das OOM, das Sie gesehen haben, KEIN Java-OOM, sondern ein Linux-Ding. Javas OOME und dieses OOM, das Sie sehen, sind völlig unterschiedlich. Sofern Sie in Ihren Anwendungsprotokollen nicht sehen, dass Java einen OutOfMemoryError ausgelöst hat, haben Sie kein Problem damit, dass Ihr Programm zu viel Heap verwendet.

Die Sache, die zu viel Heap-Speicherplatz erzeugt, ist, dass Sie die JVM so konfigurieren, dass sie 512 MB verwendet. Der JVM ist ein Junggeselle, der gerade von zu Hause ausgezogen ist, er räumt den Müll auf seinem Haufen nicht auf, bis der Haufen voller Müll ist. Wenn Sie ihm eine maximale Heap-Größe von 512 MB mitteilen, wird es, selbst wenn es nur 10 MB benötigt, die Heap-Größe weiter auf die maximale Heap-Größe erhöhen und nur dann eine GC durchführen. Und selbst nachdem es eine Garbage Collection durchgeführt hat, verwendet es die JVM aus Sicht des Betriebssystems immer noch - es gibt diesen Speicher nicht zurück an das Betriebssystem, sondern hängt daran. So funktioniert der JVM-Heap, er nimmt so viel Speicher vom Betriebssystem und behält ihn.

Wenn Sie herausfinden möchten, wie viel Heap Ihre Anwendung tatsächlich verwendet, verbinden Sie jconsole damit, gehen Sie zur Registerkarte "Speicher", klicken Sie auf die Schaltfläche, um eine vollständige GC durchzuführen, und sehen Sie dann, wie viel Speicher der Heap verwendet.

Tolle Erklärung. Ich war mir der ganzen Komplexität der GC überhaupt nicht bewusst. Danke dafür!