metaSpace Speicher concumption Fragen von Java 8-Anwendungen auf WIlfly Einsatz 8.2.1

Question

Ausgabe Beschreibung

Ich bemerkte, dass jeder Einsatz eines unserer Java8 Anwendung auf Wildfly 8.2.1 verwendet etwa 30-40 MBs von metaSpace Speicher Schwimmbad. Das ist in Ordnung, aber die Sache ist, dass, sobald ich die gleiche Anwendung erneut vertreibe, die Metaspace-Speicherbelegung um dieselben 30-40 MB erhöht wird, während der alte bereits zugewiesene Speicher nicht freigegeben wird.

Ich würde es nicht einmal bemerken, aber die Sache ist, dass wir ~ 20 Anwendungen haben und von Zeit zu Zeit muss ich bis zu 10 von ihnen gleichzeitig bereitstellen. Dies wiederum führt zu einem gruseligen Bild.

Grundsätzlich werden die 2 Umsetzungen von ~ 10 Anwendungen angezeigt.

Ich bin mir nicht sicher, warum GC den Speicher nicht freigeben kann, der den alten Klassen zugewiesen wird. Dieser Server hat insgesamt 16 GB physischen Speicher, so dass ich alle Anwendungen bis zu 20-40 mal neu bereitstellen kann und das ist es. Der App-Server erreicht das Limit und reagiert nicht mehr auf Befehle.

So wäre ich sehr dankbar, wenn mir jemand helfen könnte, zu verstehen, was das eigentliche Problem sein könnte:

1. Ist es ein Java8 Problem? (jdk 1.8.0_40-b26)
2. Ist es ein Wildfly 8.2.1 Problem?
3. Oder ist die Antwort so einfach wie möglich, dass die Ursache meine Code-Basis ist? Wenn ja, könnten Sie mir bitte sagen, was der eigentliche Grund sein könnte?

Einige weiteren Details zu meiner Code-Basis

1) Zusammen mit Wildfly ich 2 eigenständigen HornetQ Server bezogen, jede Anwendung verwendet ~ 5 Kanäle mit jeweils mindestens 5 gleichzeitigen Verbrauchern auf. Dies ergibt wiederum mindestens 25 Threads für jede App und mindestens 25 * 20 = 500 Threads insgesamt.

2) Für alle Low-Level-JMS-Operationen verwende ich Spring JMS.

Answer 1

WildFly 10.0.0.Final "java.lang.OutOfMemoryError: Metaspace" tritt auf und wird behoben. Siehe Agile Board of Wildfly

https://issues.jboss.org/browse/WFLY-6173

Answer 2

Um empirisch zu bestimmen, wo und wenn Sie ein Leck haben (Sie könnten kein Leck haben - es könnten legitime Klassen sein, die während legitimen Gründen während der Bereitstellung geladen werden), versuchen Sie taking a heap dump zur richtigen Zeit (dh vor oder nach der Anstieg im Metaspace auftritt). Nehmen Sie dann einen weiteren Heapspeicherauszug. Vergleichen Sie die beiden Heap-Dumps mit einem Tool wie MAT oder Yourkit. Der Unterschied zwischen den beiden sagt Ihnen, welche Klassen geladen werden.

Lecks im Metaspace sind ziemlich selten, weil Sie nur so viele Klassen laden müssen, aber es könnte auch ziemlich exotisch sein.

Lassen Sie mich wissen, was Sie finden und glücklich Jagd! Das macht Spaß. :-)