Tomcat oomParachute: Wie man richtig konfiguriert

Question

Mein System leidet unter OOM (vermutlich aufgrund eines DOS-Angriffs). Ich benutze Tomcat 7, NIO. Ich suche nach Wegen, um mein System robuster gegen diese Angriffe zu machen (obwohl ich nicht erwarte, Tomcat komplett immun zu machen - ich möchte die Robustheit so weit wie möglich verbessern).

Meine Protokolle zeigen:

Exception in thread "http-nio-8080-exec-285" Exception in thread "http-nio-8080-exec-82" SEVERE:Memory usage is low, parachute is non existent, your system may start failing. 
Exception in thread "PoolCleaner[216942577:1400676008859]" SEVERE:Memory usage is low, parachute is non existent, your system may start failing. 

So begann ich die oomParachute untersuchen.
Die Dokumentation (http://tomcat.apache.org/tomcat-7.0-doc/config/http.html) sagt sehr wenig:

(int) Die NIO-Anschluss eine OutOfMemoryError Strategie Fallschirm genannt implementiert. Es enthält einen Datenblock als Byte-Array. Im Falle eines OOM wird dieser Datenblock freigegeben und der Fehler wird gemeldet. Dies gibt der VM genug Raum zum Aufräumen. Die oomParachute repräsentiert die Größe des Fallschirms in Bytes (das Byte-Array). Der Standardwert ist 1024 * 1024 (1 MB). Bitte beachten Sie, dass dies nur für OOM-Fehler in Bezug auf den Java-Heap-Bereich funktioniert, und es gibt absolut keine Garantie, dass Sie überhaupt wiederherstellen können. Wenn Sie einen OOM außerhalb des Java-Heaps haben, hilft dieser Fallschirmtrick nicht.

Also ich versuche herauszufinden: Gibt es wirklich einen Standard wie das Dokument sagt? Wenn ja, warum bekomme ich "Fallschirm ist nicht existent"?
Sollte ich einen Fallschirm definieren? Welchen Wert sollte ich dort setzen? Welche Parameter spielen eine Rolle bei der Bestimmung des Wertes dieses Parameters? (Anzahl der gleichzeitigen Verbindungen? erwartete Größe der Anfrage? Gesamt Heap?)

Was macht dieser Fallschirm wirklich?

Danke!

Answer 1

Da die docs sagt, ist diese Parachute einfach ein byte[] zugeordnet, so dass im Falle eines OutOfMemory Fehler kann es freigegeben werden, so dass die Wirkung der Berichterstattung, sagte OutOfMemory ausgeführt werden können. Da das System bereits über keinen verfügbaren Speicher verfügt, ist es unwahrscheinlich, dass Sie das Problem beheben.

Diese Fehlermeldung an der NioEndpoint Klasse hartcodiert ist: http://grepcode.com/file/repository.springsource.com/org.apache.coyote/com.springsource.org.apache.coyote/6.0.24/org/apache/tomcat/util/net/NioEndpoint.java#NioEndpoint.0oomParachuteData (scrollen Sie einfach ein wenig nach unten, und Sie werden es, direkt unter dem oomParachute sehen - es checkParachute periodisch eingestellt ist(), Linie 694 und Linie 1331 Sie können sehen, wie es verwendet wird, und einige Entwickler Humor)

Wahrscheinlich Bedeutung "Hey, ich habe gerade den Fallschirm verwendet, du bist jetzt auf eigene Faust!" hehe.

Für die Einstellung auf einen vernünftigen Wert, hängt es weitgehend davon ab, wie viel Arbeitsspeicher Sie zur Verfügung haben, wie viel RAM Ihr System normalerweise verwendet, wie viel RAM es normalerweise in Spitzenzeiten und einige andere Faktoren verwendet. Allerdings soll dieser "Fallschirm" Sie nicht retten. Machen Sie den OutOfMemory-Fehler etwas weicher, damit er protokolliert werden kann.

Ich persönlich empfehle JavaMelody für die Verfolgung Ihrer Speicherauslastung und haben eine allgemeine "Was ist los" mit Ihrem Server. Es kann Ihnen Speicherverbrauch, CPU-Auslastung, alle laufenden Threads und was sie tun, SQLs, die Sie ausgeführt haben und vieles mehr: https://github.com/javamelody/javamelody/wiki - Es ist wirklich einfach zu installieren und zu verwenden.