Jak dostroić jvm do awarii zamiast heroicznej GC do 100% wykorzystania procesora?

Question

Mamy proces JVM, który rzadko peguje procesor na 100%, z czym wydaje się być (zgodnie z visualgc) bardzo prawie wyczerpaną stertą. Przypuszczamy, że proces ten jest heroicznie GC'ing powodując skok procesora, który wpływa na ogólny stan całego systemu (składający się z innych maszyn JVM wykonujących różne czynności).

Ten proces nie jest krytyczny i można go ponownie uruchomić. Czy istnieje sposób na dostrojenie maszyny JVM za pomocą linii poleceń, która uruchamia ją, aby spadła na własny miecz, zamiast utrzymywać GC i spowodować cierpienie całego pudła?

Warto zauważyć, że nie dostaniemy OOMExceptions, więc kupa nie jest CAŁKOWICIE wyczerpana, ale ledwo nie, myślimy.

Alternatywnie, coś, co daje nam pewien wgląd w to, co w JVM faktycznie używa procesora w taki sposób, aby potwierdzać/zaprzeczać naszemu przypuszczeniu GC?

Answer 1

Musisz znaleźć sposób na zebranie statystyk dotyczących pracy GC. W rzeczywistości istnieją pewne metody, aby to zrobić. Nie będę robić kopiuj-wklej, tylko daje link do podobnych pytanie:

Can you get basic GC stats in Java?

wierzę, będziesz myśleć jak analizować tę statystykę i decydowania kiedy GC jest stale aktywny.

Ponieważ to pytanie zawiera kilka nowych pomysłów na zastosowanie statystyki GC, nie sądzę, że jest duplikatem.

Answer 2

Najlepszą rzeczą do zrobienia jest znalezienie wycieku pamięci i naprawienie go.

Prostym sposobem, aby wyjść na wysokie zużycie pamięci:

if(Runtime.getRuntime().totalMemory()>100*1024*1024) 
    System.exit(0); 

Answer 3

Spróbuj spojrzeć jakie procesy są uruchomione na JVM.

• z jstack można zrobić zrzut wątek (istnieją inne sposoby, aby to zrobić, jak również)
• z jvisualvm można zajrzeć do aktualnego stanu JVM (trwa jakieś zasoby)
• również włączyć na verbosegc (aby udowodnić swoje założenie, że GC jest częste)

Answer 4

równoległe i równoczesne kolektory mają „overhead Limit”, że może robić to, co chcesz:

jeśli więcej niż 98% całego czasu spędzony w zbierania śmieci, a mniej niż 2% hałdy odzyskuje An OutOfMemoryError zostanie wyrzucony

Patrz http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html więcej informacji.

Answer 5

Możemy statystyki z

1): Opcja -XX: + PrintGCTimeStamps doda datownik na początku każdej kolekcji. Jest to przydatne, aby zobaczyć, jak często pojawiają się śmieci.

Dzięki powyższej opcji możemy z grubsza oszacować, czy przypuszczasz, że proces jest heroicznie GC'ing powodujący skok procesora, czy nie.

Jeśli Twoja suppossition jest właściwa, rozpocznij dostosowywanie GC.

Both parallel collector and Concurrent Collector will throw an OutOfMemoryError if too much time is being 
spent in garbage collection: if more than 98% of the total time is spent in garbage collection and 
less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. the option X:-UseGCOverheadLimit 
is enabled by default for both Parallel and concurrent collector . Check whether this option is disabled in 
your system . 

Aby uzyskać więcej informacji na temat strojenia Gc w JVM odnoszą this i VM sprawdzić opcje debugowania this