Linux używający systemu/procesora jądra z uruchomioną Javą GC

Question

Informacja o tle Som;

Serwer;

Nowy serwer SLES 12 z pamięcią 130 GB, przeznaczony do uruchamiania MySQL dla dużej bazy danych (150G + danych).

Serwer będzie również hostować niektóre aplikacje Java.

wersja Java (domyślnie z Oracle) - Java (TM) SE Runtime Environment (build 1.7.0-b147) - Java HotSpot (TM) 64-bitowy serwer VM (build 21,0-B17, tryb mieszany)

Natknęliśmy się na następujący problem;

Uruchamianie niektórych aplikacji Java java powoduje spowolnienie działania procesora kerne/system/zatrzymanie aplikacji na czas postoju. Odtworzyłem go, tworząc aplikację Java, która po prostu zjada pamięć w czasie i używa procesora.

Dochodzenia wykazują dużą liczbę interwencji podczas spowolnienia (10000-25000).

Po każdym spowolnieniu Java zdobyła nieco więcej pamięci. Ustawienie Java, aby rozpocząć od stałej pamięci wydaje się również zmniejszyć problem (ustawienie -Xmx i -Xms na tę samą wartość). Zbieżny odbiór śmieci wskazuje również, że GC zaczyna działać i może być wyzwalaczem.

GC i alokacja pamięci jest z jakiegoś powodu bardzo kosztowna, a nie jesteśmy pewni, gdzie szukać. Rozwlekły z GW:

[GC^C 1024064K->259230K(3925376K), 87,3591890 secs] 

Na serwerze low-end linux sam program działa GC (z systemem SLES, Java 1.6.0_11 od SUN);

[GC 1092288K->253266K(3959488K), 3.0125460 secs]  

górę podczas spowolnienia:

top - 11:23:33 up 87 days, 19:55, 5 users, load average: 14.27, 4.50, 10.17 
Tasks: 250 total, 39 running, 211 sleeping, 0 stopped, 0 zombie 
Cpu(s): 0.0%us, 71.8%sy, 0.0%ni, 28.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 129033M total, 128576M used,  457M free,  1388M buffers 
Swap: 32765M total,  13M used, 32752M free, 113732M cached 

vmstat podczas osłabienia (od 3. wiersz);

procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------ 
r b swpd free buff cache si so bi bo in cs us sy id wa st 
0 0 13552 1714328 1422268 116462260 0 0 10  9 0 0 0 0 100 0 0 
1 0 13552 1241780 1422268 116462292 0 0  0  0 240 353 1 0 99 0 0 
1 0 13552 695616 1422268 116462292 0 0  0 17 419 431 3 0 97 0 0 
55 0 13552 486384 1422268 116462292 0 0  0  2 20228 458 1 57 43 0 0 
75 0 13552 476172 1422268 116462300 0 0  0  8 12782 684 0 70 30 0 0 
65 0 13552 470304 1422268 116462304 0 0  0  0 13108 792 0 72 28 0 0 

Dlaczego jest tak drogie GC na wysokim serwera końcowego kontra serwerze low end? Wszelkie pomysły, gdzie szukać wskazówek?

AKTUALIZACJA - wywołaj parametry 2012-11-26 Wywołaj parametry;

java -Xmx4g -Xms4g -verbose:gc -server -cp "./dest/" UseMemoryMain 

Nadanie

[GC^C 1024064K->259230K(3925376K), 87,3591890 secs] 

Zmieniono;

java -Xmx4g -Xms4g -XX:+UseParallelGC -verbose:gc -cp "./dest/" UseMemoryMain 

Nadanie

[GC 1048640K->265430K(4019584K), 0,0902660 secs] 

Zmieniono;

java -Xmx4g -Xms4g -XX:+UseConcMarkSweepGC -verbose:gc -cp "./dest/" UseMemoryMain 

Nadanie

[GC 1092288K->272230K(3959488K), 0,1791320 secs] 

Jaki jest prawdziwy śmieszne jest to, że ponowne uruchomienie dzisiaj bez mówienia która metoda GC użycie daje to;

java -Xmx4g -Xms4g -verbose:gc -server -cp "./dest/" UseMemoryMain 

Nadanie

[GC 1024064K->259238K(3925376K), 0,0839190 secs] 

Java zmieniły strategię zalegających GC jakoś ...

Answer 1

Garbage Collection jest rzeczywiście skomplikowany temat. Aby dać najlepszą odpowiedź, powinieneś opublikować kompletny wiersz poleceń użyty do wywołania java.

Jak już powiedziałeś, gra na mieliźnie z przełącznikami GC pomaga. Powodem jest to, że ustawienia domyślne nie są niestety optymalne dla wielu aplikacji używanych w dzisiejszych czasach. Dla wielu wielu aplikacjach, które są wymagane, aby mieć szybkich odpowiedzi, ponieważ są interaktywne, parametr

-XX: + UseConcMarkSweepGC

uczyni wielką różnicę.

Warto zauważyć, że przy użyciu wspomnianej maszyny JVM używanie większych hałd (powiedzmy, że większe 10 GB) będzie zawsze wymagało pewnego strojenia. Zapoznaj się z logiem GC i obserwuj, jak zmienia się zachowanie podczas gry z opcjami GC. Polecam wypróbować różne strategie kolekcjonerskie (takie jak CMS lub G1), a także grać z konfiguracją Eden Space (jak Xmn).

Ostatni, ale nie mniej ważny, możesz zbadać, co robi aplikacja z pamięcią za pomocą profilera. Być może kod można poprawić, dzięki czemu można uniknąć wielu czynników GC.