GoldenLine
Zaloguj się

konto usunięte

Temat: wąskie gardło w aplikacji j2ee

Witajcie,
mam dość obszerną aplikację j2ee i w trakcie jej działania coś nie jest odśmiecane i wszystko niemiłosiernie zwalnia. Nie mogę dość po kodzie gdzie to jest. Czym mogę sprawdzić gdzie aplikacja ładuje dużo stuffu do pamięci?
Link do wypowiedziLink

konto usunięte

Temat: wąskie gardło w aplikacji j2ee

Z JDK z paczki masz takie oto narzędzie diagnostyczne:

jconsole

pzdrPaweł W. edytował(a) ten post dnia 15.09.09 o godzinie 12:40
Link do wypowiedziLink
Michał Podsiadłowski

Michał Podsiadłowski J2EE Developer

Temat: wąskie gardło w aplikacji j2ee

Profilerem jakimś, polecam Jprofiler - płatny ale 30 dni darmo.
Link do wypowiedziLink

konto usunięte

Temat: wąskie gardło w aplikacji j2ee

Paweł W.:
Z JDK z paczki masz takie oto narzędzie diagnostyczne:

jconsole

pzdrPaweł W. edytował(a) ten post dnia 15.09.09 o godzinie 12:40

Si, tyle że przy jego pomocy nie mogę sprawdzić która klasa mi tak bałamuci :(
Link do wypowiedziLink
Krzysztof K.

Krzysztof K. Experienced Software
Engineer

Temat: wąskie gardło w aplikacji j2ee

Andrzej K.:
Paweł W.:
Z JDK z paczki masz takie oto narzędzie diagnostyczne:

jconsole

pzdrPaweł W. edytował(a) ten post dnia 15.09.09 o godzinie 12:40

Si, tyle że przy jego pomocy nie mogę sprawdzić która klasa mi tak bałamuci :(

W JProfilerze mozesz pofiltrowac po pakietach, klasach i według "allocated bytes".
Link do wypowiedziLink

konto usunięte

Temat: wąskie gardło w aplikacji j2ee

Stwierdzenie "potwornie zwalnia" jest dosyć ogólne i raczej bym nie czepiał się GC ponieważ po dłuższym czasie dostałbyś OutOfMemory, a z informacji które podałeś wygląda na to że Java działa dalej. Jak leci to wówczas polecam Visual GC.

Sprawdź bazę danych, czy nie wiszą na niej transakcje i zapisy. Czy nie ma deadlocków. Ogólnie w trakcie działania śledź logi na poziomie WARN - możliwe że wcześniej niż zaczyna się "spowolnienie" Hibernate albo inna biblioteka zgłasza jakiś problem.
Profiler generuje masę informacji, których czytelność jest znikoma.

Pozdrawiam,
Łukasz
--
Code-House
http://code-house.org/
Bądź niezależny. Wybierz Open Source.
Link do wypowiedziLink
Krzysztof K.

Krzysztof K. Experienced Software
Engineer

Temat: wąskie gardło w aplikacji j2ee

Łukasz Dywicki:
Stwierdzenie "potwornie zwalnia" jest dosyć ogólne i raczej bym nie czepiał się GC ponieważ po dłuższym czasie dostałbyś OutOfMemory [...]

Nie do konca tak to dziala. Najczesciej caly heap space podzielony jest na generacje i dopoki nie odpala sie zbyt czesto "Full GC", ktory odpowiedzialny jest za czyszczenie calego obszaru pamieci, doputy OutOfMemoryError nie musi zostac wyrzucony:)

Mozliwe, ze sam heap jest za maly wtedy zbyt czesto wlacza sie "Full GC", ktory powoduje slynne "Stop-the-world" i w rezultacie aplikacja jest przez wiekszosc czasu "zblokowana" przez watek GC.

Oczywiscie, moze to byc tak jak napisales problem bibilioteki, deadlock'ow czy wait'ow na semaforach itp.Krzysztof K. edytował(a) ten post dnia 13.10.09 o godzinie 12:26
Link do wypowiedziLink

konto usunięte

Temat: wąskie gardło w aplikacji j2ee

Nie podałeś wszystkich szczegółów, ale ja spotkałem się z taką historią:
Na stertę było przeznaczone 2GB. Po wgraniu nowej wersji aplikacji system w pewnym momencie zwalniał do tego stopnia że praktycznie nie obsługiwał żadnego żądania - działo się tak codziennie.
Informacje o obiektach na stercie nie wskazywały niczego niepokojącego. Okazało się po analizie logów GC że pełne odśmiecanie było wykonywane raz dziennie, w okolicach wspomnianych problemów.
Zalecono zmniejszenie sterty do 1G i problemy ustąpiły.
Link do wypowiedziLink

konto usunięte

Temat: wąskie gardło w aplikacji j2ee

Krzysztof K.:
Łukasz Dywicki:
Stwierdzenie "potwornie zwalnia" jest dosyć ogólne i raczej bym nie czepiał się GC ponieważ po dłuższym czasie dostałbyś OutOfMemory [...]

Nie do konca tak to dziala. Najczesciej caly heap space podzielony jest na generacje i dopoki nie odpala sie zbyt czesto "Full GC", ktory odpowiedzialny jest za czyszczenie calego obszaru pamieci, doputy OutOfMemoryError nie musi zostac wyrzucony:)

Mozliwe, ze sam heap jest za maly wtedy zbyt czesto wlacza sie "Full GC", ktory powoduje slynne "Stop-the-world" i w rezultacie aplikacja jest przez wiekszosc czasu "zblokowana" przez watek GC.

Oczywiscie, moze to byc tak jak napisales problem bibilioteki, deadlock'ow czy wait'ow na semaforach itp.

Częste Full GC nie spowoduje zawieszenia się procesu JVM na wieczność, dlaczego? Ponieważ to GC musiało by być uruchamiane non stop. Sam stop the world jest uruchamiany tak by trwał jak najkrócej więc nie winił bym go za to, bo zwykle czas jego trwania liczy się w milisekundach.
Nawet na domyślnych ustawieniach wirtualnej maszyny ciężko jest doprowadzić do tego by GC uruchamiało się non-stop.
--
Code-House
code-house.org/
Bądź niezależny. Wybierz Open Source.Łukasz Dywicki edytował(a) ten post dnia 09.11.09 o godzinie 09:49
Link do wypowiedziLink
Krzysztof K.

Krzysztof K. Experienced Software
Engineer

Temat: wąskie gardło w aplikacji j2ee

Łukasz Dywicki:

Częste Full GC nie spowoduje zawieszenia się procesu JVM na wieczność, dlaczego?

Na wiecznosc nie ale z doswiadczenia wiem, ze moze zawiesic proces na kilka dni i konsumowac w tym czasie 99% czasu procesora :)
Link do wypowiedziLink

konto usunięte

Temat: wąskie gardło w aplikacji j2ee

Krzysztof K.:
Łukasz Dywicki:

Częste Full GC nie spowoduje zawieszenia się procesu JVM na wieczność, dlaczego?

Na wiecznosc nie ale z doswiadczenia wiem, ze moze zawiesic proces na kilka dni i konsumowac w tym czasie 99% czasu procesora :)

To zależy jeszcze od tego jaka jest JVM i jakie kolektory są ustawione w parametrach JVM. Jeśli np. mamy JVM Sunowską i jeśli dla obszaru TENURED ustawiony jest kolektor ConcurentCollector to wątki aplikacji zawieszane są tylko na bardzo któtki okres w celu zrobienia "migawki sterty". Samo odśmiecane jest realizowane przez wątki działające równocześnie z wątkami aplikacji.
A przynajmniej tak powinno być w teorii.Marek K. edytował(a) ten post dnia 17.11.09 o godzinie 12:28
Link do wypowiedziLink
Krzysztof K.

Krzysztof K. Experienced Software
Engineer

Temat: wąskie gardło w aplikacji j2ee

Marek K.:
A przynajmniej tak powinno być w teorii.

Dokladnie. Powinno byc ale mi sie zdarzylo kilka razy, ze JVM sie zawiesil.

<GCH: vm="Java HotSpot(TM) Server VM mixed mode" >
<GCH: vmrelease="1.4.2 1.4.2.05-040917-18:54-PA_RISC2.0 PA2.0 (aCC_AP)" >
Link do wypowiedziLink
Adam Foltyn

Adam Foltyn architekt /
programista - java

Temat: wąskie gardło w aplikacji j2ee

Ja mam trochę inny problem. Próbuję różnych ustawień pamięci dla jboss-a, ale nie udaje mi się ograniczyć liczby wywołań pełnego GC. Szczerze mówiąc nie wiem dlaczego jest on wywoływany tak często, mimo jeszcze dużej rezerwy pamięci. Dla przykładu:
520.455: [Full GC [PSYoungGen: 15109K->0K(318528K)] [PSOldGen: 147795K->162737K(1179648K)] 162904K->162737K(1498176K) [PSPermGen: 89996K->89996K(176640K)], 2.5629790 secs]
Takie serie wywołań są co kilka sekund, potem dłuższa przerwa i znowu.
Ma ktoś koncepcję dlaczego tak się dzieje albo co mogę jeszcze ustawić?

na razie mam takie parametry
-Xms1536m -Xmx1536m -XX:MaxPermSize=512m -Xss256k -XX:NewRatio=3 -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000Adam Foltyn edytował(a) ten post dnia 18.11.09 o godzinie 10:48
Link do wypowiedziLink
Krzysztof K.

Krzysztof K. Experienced Software
Engineer

Temat: wąskie gardło w aplikacji j2ee

Adam Foltyn:
-Xms1536m -Xmx1536m -XX:MaxPermSize=512m -Xss256k -XX:NewRatio=3 -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000Adam Foltyn edytował(a) ten post dnia 18.11.09 o godzinie 10:48

Na wszelki wypadek dodalbym -XX:+DisableExplicitGC
bo moze w jakis sposob programowo wolany jest System.gc().
Jezeli masz wiecej niz 1 proc (rdzen) to moze warto uzyc parallel collector'a do mlodej i starej generacji czyli:
-XX:+UseParallelGC
-XX:+UseParallelOldGC
Moze to wplynac znacznie na dlugosc cyklu FullGC.
Co do czestotliwosci z jaka sie odpala to trzeba by pokombinowac troche z wielkoscia mlodej i starej generacji. Z tego co widze to w starej generacji zostaje 162737K obiektow po FullGC i w porownaniu do pamieci 1179648K calej starej generacji jest to bardzo malo. Dziwne, ze w ogole FullGC zdecydowal sie odpalilc przy takim stanie pamieci.
Link do wypowiedziLink

konto usunięte

Temat: wąskie gardło w aplikacji j2ee

Adam Foltyn:
Ja mam trochę inny problem. Próbuję różnych ustawień pamięci dla jboss-a, ale nie udaje mi się ograniczyć liczby wywołań pełnego GC. Szczerze mówiąc nie wiem dlaczego jest on wywoływany tak często, mimo jeszcze dużej rezerwy pamięci. Dla przykładu:
520.455: [Full GC [PSYoungGen: 15109K->0K(318528K)] [PSOldGen: 147795K->162737K(1179648K)] 162904K->162737K(1498176K) [PSPermGen: 89996K->89996K(176640K)], 2.5629790 secs]
Takie serie wywołań są co kilka sekund, potem dłuższa przerwa i znowu.
Ma ktoś koncepcję dlaczego tak się dzieje albo co mogę jeszcze ustawić?

na razie mam takie parametry
-Xms1536m -Xmx1536m -XX:MaxPermSize=512m -Xss256k -XX:NewRatio=3 -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000Adam Foltyn edytował(a) ten post dnia 18.11.09 o godzinie 10:48

Ja z kolei zrobiłbym na początek dwie rzeczy:
- zmnieniłbym ustawienia dla PermGen z -XX:MaxPermSize=512m na -XX:MaxPermSize=100m (i tak widać że zajęcie obszaru jest stałe i nie przekracza 90m)
- Ustawiłbym większy obszar New parametrami: -XX:NewSize=744m -XX:MaxNewSize=1024m
Link do wypowiedziLink
Adam Foltyn

Adam Foltyn architekt /
programista - java

Temat: wąskie gardło w aplikacji j2ee

Z tym DisableExplicitGC to dobry pomysł. Sprawdziłem co prawda czy w naszej aplikacji nikt nadgorliwie nie wywołuje GC, ale nigdy nie wiadomo co robi jboss albo jakieś biblioteki zależne.

Rozmiar młodej generacji próbuję stopniowo zwiększać tym parametrem NewRatio, ale chyba faktycznie łatwiej operować tym NewSize

PermGen jest ustawiony na tak duży bo w jbossie jest problem ze zwalnianiem obiektów w tej części, szczególnie przy redeploymencie. Ale limit 512 to chyba i tak dużo za dużo.

Na koniec zostawię sobie próby z UseParallelGC.

Jako że to testy "na żywym organizmie", zajmą mi pewnie kilka dni, ale dam znać co się zmieniło.

Dzięki za pomoc
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Administrator Aplikacji - J2EE




Wyślij zaproszenie do
Anuluj