2015-05-28 13 views
10

Pracujemy na wyroczni java-8.java.lang.OutOfMemoryError: Skompresowana przestrzeń klasowa

Przeprowadziliśmy się do java8 sześć miesięcy temu.

W ciągu ostatnich kilku dni otrzymywaliśmy OOMY od czasu do czasu i nie byliśmy w stanie zidentyfikować ani odtworzyć problemu.

Gdy wykonujemy połączenia z serwerem (Tomcat) otrzymujemy ten błąd na stacktrace:

java.lang.OutOfMemoryError: Compressed class space 

Ponowne uruchomienie serwera rozwiązuje problem. To samo połączenie z innym serwerem działa, tak samo jak inne połączenie innego typu z tym samym serwerem.

Patrząc na gc.log widzimy:

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 Powroty:

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 

nie widzę żadnych problemów z pamięcią albo w jstat zalogować lub w dzienniku GC.

Próba uruchomienia jmap -clstats zawiesza:

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

Z jakimi XMS i xmx przełączniki czy uruchomić JVM? Polecam użyć visualvm lub podobnego narzędzia, aby lepiej zobaczyć i dowiedzieć się, jak konfigurowane są rozmiary maszyny JVM. Lub użyj Eclipse Memory Analyzer. Na razie możesz spróbować zwiększyć przestrzeń klas skompresowanych za pomocą -XX: CompressedClassSpaceSize. Aby lepiej przeanalizować problem, należy ustawić maszynę JVM do zrzucania sterty na OOME. – Marged

+0

Po jakim czasie widzisz ten wyjątek? Czy próbowałeś zwiększyć CompressedClassSpace? mi.g: -XX: CompressedClassSpaceSize = 1g? Jeśli problem pojawi się ponownie, ale po dłuższym czasie wydaje się, że ma jakiś wyciek pamięci. –

+0

@DavidG - pierwsze spotkanie 2 dni temu na jednym z serwerów (nie wdrożyliśmy nowej wersji). Uruchom ponownie serwer, a następnie zobaczysz go ponownie po 12 godzinach tylko na jednym z serwerów. Załaduj ładunek dosnt pomoc do odtworzenia. Rozmiar kompresji pozostaje prawie taki sam i nie jest bliżej wartości 1G, która jest domyślna. – user1236097

Odpowiedz

5

sprężonym Oops i ścisłego klasie wskaźnikami dostępna przestrzeń na zajęciach jest ograniczona ze względu na konieczność wskaźnik przekręcona. 1 GB w twoim przypadku.

To dużo zajęć, więc może to oznaczać, że coś w aplikacji tworzy wiele klas i nigdy ich nie zwalnia. Przeładowanie aplikacji może?

Jeśli masz pewność, że Twoja aplikacja wymaga tylko dużej ilości pamięci dla klas, możesz spróbować podważyć limit przez -XX:CompressedClassSpaceSize=... lub wyłączyć kompresowane wskaźniki klas przez -XX:-UseCompressedClassPointers.

Zwróć uwagę, że domyślnie skompresowana przestrzeń klasy + skompresowana sterta (+ trochę narzut) nie może przekraczać 32 GB. Chociaż AIUI, zmiana wyrównania obiektu może jeszcze bardziej zwiększyć ten limit.

W przeciwnym razie należy pobrać heapdump i przeanalizować, co trzyma na załadowanych klasach.

+0

W dzienniku programu jstat można zobaczyć, że CCSU to 1048576.0, a CCSU to 11339,1. – user1236097

+1

może być fragmentacja? Nie sądzę, że przestrzeń klasowa zostanie skompaktowana. Chociaż taki ogromny czynnik jest dziwny, nawet jeśli był to fragmentacja. Poza tym myślę, że jesteś wyłączony przez jedną kolumnę, ale nadal pozostaje rozbieżność. – the8472

+0

Można uruchomić to zobaczyć sprawdzić, czy ja źle w kolumnach: echo „S0C S1C S0U S1U WE UE OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT \ n 87296,0 87296,0 0,0 3151,4 523776,0 148284,4 3.495.936,0 574.868,5 1.395.640,0 98.066,3 1.048.576,0 11.339,1 12165 636,851 223 116,957 753,808 "| kolumna -t – user1236097

7

Napotkaliśmy podobny problem. Niestety sterty nie pomogą, ponieważ klasy nie są w stercie, ale w pamięci macierzystej. Włącz je w ustawieniach JVM rozwiązywać klas załadowane:

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

W naszym przypadku sprawa była JAXBContext.newInstance nie będąc singleton.

Powodzenia Albert

Powiązane problemy