2017-10-05 103 views
18

Wyłączyłem 1 wystąpienie (2 procesory wirtualne, 2 GB pamięci RAM, ładowanie ~ 4k kw./S) do środowiska Java 9 (z najnowszej wersji Java 8). Przez chwilę wszystko było w porządku, a użycie procesora było takie samo jak wcześniej. Jednak po ~ 6 godzinach zużycie procesora wzrosło o 4% (z 21% do 25%) bez powodu. Nie miałem żadnych skoków, nie zwiększono zużycia pamięci, żadnych zmian metryki (mam liczniki dla każdej metody w kodzie). Nic.Dlaczego występuje spadek wydajności po ~ 6 godzinach pracy Java 9 G1 bez faktycznego wzrostu obciążenia?

Pozostawiłem tę instancję nietkniętą na ~ 12 godzin, spodziewając się, że zostanie ona przywrócona. Ale nic się nie zmieniło. Po prostu zaczęło zużywać więcej CPU. Polecenie

top pokazało, że instancja miała więcej impulsów procesora niż zwykle dla procesu serwera Java. Czytałem ostatnio, że G1 nie nadaje się do wysokiej przepustowości. Więc doszedłem do wniosku, że powodem może być G1.

I wznowiona wystąpienie z:

java -XX:+UseParallelGC -jar server-0.28.0.jar 

A po ~ 20 godzin monitorowania, wszystko jest w porządku, jak wcześniej. Zużycie procesora jest na poziomie 21%, jak było wiele dni wcześniej.

wykorzystanie procesora bezpośrednio po Java 9 rozmieszczenia (skala 6H)

enter image description here

wzrost procesora przez 7 godzin w + 12 godzin "nietknięta" (skala 7d):

enter image description here

Procesor po - XX:+UseParallelGC (skala 24h):

enter image description here

Moje pytanie brzmi - czy to oczekiwane zachowanie dla G1? Ktoś jeszcze widzi coś podobnego?

Ubuntu 16.04 x64

java version "9" 
Java(TM) SE Runtime Environment (build 9+181) 
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) 
+2

Czy zdarzyło Ci się zobaczyć dzienniki GC w tym momencie (skala 6h)? Byłoby dobrze, gdybyśmy wykluczyli * wątpliwe * podejrzenia względem GC i zapewnili zaufanie, aby poznać dokładną przyczynę. – nullpointer

+0

Nie :(To jest instancja produkcyjna, więc nie chciałem ryzykować. –

+3

tak ... bez logów jest to niemożliwe (poza domniemaniem zakładam) – Eugene

Odpowiedz

-4

nie mam ostateczną odpowiedź, ale używamy psi-probe monitorować nasze JVM (nasz pojemników aplikacyjnych - Tomcat 8+ używasz JDK 1.8 do obsługi dynamicznych stron), które mogą zapewni świetny obraz wykorzystania pamięci JVM (Eden, Survivor, Old Gen itp.) wraz z wykorzystaniem procesora, co może pomóc w rozwiązaniu problemu z algorytmem odśmiecania, który umieszczasz w pracy.

Psi-sonda jest łatwa do wdrożenia w dowolnym środowisku - niezależnie od tego, czy chodzi o produkcję czy rozwój. Gdybym był tobą, również bym to zrobił, a także umożliwiłbym logowanie gc jako sugerowane .. w twoim środowisku DEVEL i przeprowadzić test obciążenia (zawsze widzę JMeter jako bardzo przydatne narzędzie w takich przypadkach - proste, ale mocne), aby sprawdzić, czy Mogę powtórzyć problem. Wciśnij różne obciążenia i obserwuj zachowanie JVM w czasie rzeczywistym za pomocą sondy psi.

+0

Ta odpowiedź nie dostarcza bardzo przydatnych informacji. psi-sonda jest używana dla tomcat, ale OP nie wspomina o używaniu tomcat i koncentruje się na Javie 9 w ogóle. –