java.lang.OutOfMemoryError: Komprimierter Klassenraum

Wir laufen auf Java-8-Oracle.java.lang.OutOfMemoryError: Komprimierter Klassenraum

Wir sind vor sechs Monaten nach java8 umgezogen.

In den letzten Tagen haben wir von Zeit zu Zeit ein OOME bekommen und konnten das Problem nicht identifizieren oder reproduzieren.

Wenn wir einen Aufruf an den Server (Tomcat) führen wir diesen Fehler auf dem Stacktrace erhalten:

java.lang.OutOfMemoryError: Compressed class space

Neustart des Servers löst das Problem. Derselbe Aufruf an einen anderen Server funktioniert ebenso wie ein anderer Aufruf eines anderen Typs an denselben Server.

Wenn auf dem gc.log suchen wir sehen:

2015-05-27T16:05:42.991+0000: 98774.440: [Full GC (Last ditch collection) 98774.440: [CMS: 575745K->575330K(3495936K), 0.8687777 secs] 575745K->575330K(4107008K), [Metaspace: 97940K->97940K(1396736K)], 0.8696093 secs] [Times: user=0.95 sys=0.00, real=0.88 secs] 
2015-05-27T16:05:55.486+0000: 98786.935: [Full GC (Metadata GC Threshold) 98786.935: [CMS: 573414K->578735K(3495936K), 0.9372859 secs] 925046K->578735K(4107008K), [Metaspace: 99428K->99428K(1396736K)], 0.9386626 secs] [Times: user=1.01 sys=0.00, real=0.94 secs]

jstat -gc kehrt:

S0C S1C S0U S1U  EC  EU  OC   OU  MC  MU CCSC CCSU YGC  YGCT FGC FGCT  GCT 
87296.0 87296.0 0.0 3151.4 523776.0 148284.4 3495936.0 574868.5 1395640.0 98066.3 1048576.0 11339.1 12165 636.851 223 116.957 

753.808

Ich sehe keine Probleme mit dem Speicher entweder in der jstat einloggen oder im gc-Protokoll.

Der Versuch jmap -clstats hängt auszuführen:

Attaching to process ID 5110, please wait... 
Debugger attached successfully. 
Server compiler detected. 
JVM version is 25.25-b02 
finding class loader instances ..

Quelle

2015-05-28 user1236097

Mit dem Xms und Xmx Switche starten Sie die JVM? Ich empfehle Ihnen, visualvm oder ein ähnliches Tool zu verwenden, um besser zu sehen und zu lernen, wie Ihre JVM-Größen eingerichtet sind. Oder verwenden Sie Eclipse Memory Analyzer. Vorläufig können Sie versuchen, den Speicherplatz für komprimierte Klassen mit -XX: CompressedClassSpaceSize zu erhöhen. Um das Problem besser zu analysieren, sollten Sie die JVM auf Heap-Dump auf OOME festlegen. – Marged

Nach welcher Zeit sehen Sie diese Ausnahme? Haben Sie versucht, den CompressedClassSpace zu erhöhen? e.g: -XX: KomprimierteClassSpaceSize = 1g? Wenn Sie das Problem erneut sehen, haben Sie nach einer längeren Zeit ein Speicherleck. –

@DavidG - erste Begegnung vor 2 Tagen in einem der Server (wir haben keine neue Version bereitgestellt). Server neu starten und dann nach 12 Stunden in nur einem der Server wieder sehen. Stressbelastung Dosnt helfen zu reproduzieren. Die Größe der Komprimierung bleibt fast gleich, und sie ist nicht näher an 1G, was der Standard ist. – user1236097

mit Druck oops und Druck Klasse Zeiger der zur Verfügung stehende Raum für die Klassen aufgrund der notwendigen Zeiger Mangeln eingeschränkt ist. 1 GB in Ihrem Fall.

Das ist eine Menge Klassen, also könnte dies ein Hinweis darauf sein, dass etwas in Ihrer Anwendung viele Klassen erstellt und sie niemals freigibt. Anwendungs-Reload vielleicht?

Wenn Sie sicher sind, dass Ihre Anwendung nur so viel Speicher für Klassen benötigt, können Sie das Limit über -XX:CompressedClassSpaceSize=... stoßen oder komprimierte Klassenzeiger über -XX:-UseCompressedClassPointers deaktivieren.

Beachten Sie, dass standardmäßig komprimierte Klassenraum + komprimierter Heap (+ einige Overhead) 32 GB nicht überschreiten können. Obwohl AIII die Objektausrichtung ändern kann, kann diese Grenze weiter steigen.

Andernfalls sollten Sie einen Heapdump nehmen und analysieren, was die geladenen Klassen enthält.

Quelle

2015-05-28 16:13:15 the8472

Sie können im Protokoll jstat sehen, dass CCSU 1048576.0 und CCSU 11339.1 ist. – user1236097

könnte Fragmentierung sein? Ich denke nicht, dass Klassenraum verdichtet wird. Obwohl solch ein großer Faktor ist seltsam, auch wenn es Fragmentierung wäre. Außerdem denke ich, dass Sie eine Spalte entfernt sind, bleibt eine Diskrepanz. – the8472

Sie können dies ausführen überprüfen, ob ich falsch in Spalten: echo „S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT \ n 87.296,0 87.296,0 0,0 3.151,4 523.776,0 148.284,4 3.495.936,0 574.868,5 1.395.640,0 98.066,3 1.048.576,0 11339,1 12165 636.851 223 116.957 753.808 "| Spalte -t – user1236097

Wir sahen uns einem ähnlichen Problem gegenüber. Leider helfen die Heapdumps nicht, da sich die Klassen nicht im Heap, sondern im nativen Speicher befinden. Aktivieren Sie diese in Ihrer JVM-Einstellungen, die Klassen zu beheben geladen:

-XX: + PrintGCDetails -XX: + TraceClassUnloading -XX: + TraceClassLoading

In unserem Fall das Problem war JAXBContext.newInstance nicht Singletons zu sein.

Viel Glück, Albert

Quelle

2016-05-17 10:22:09 Albert

java.lang.OutOfMemoryError: Komprimierter Klassenraum

Antwort

Verwandte Themen