PermGen

Witam,
od dłuższego już czasu nurtuje Mnie problem związany z pamięcią w javie. Redeploy na jetty czy tomcacie po jakimś czasie doprowadza do przekroczenia permSpace, co jest dość uciążliwe. Jak na razie żadne googlanie nie dało sensownego rozwiązania, żadne
-Xmx228m -XX:+UseConcMarkSweepGC -XX:MaxPermSize=500m -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+DisableExplicitGC

ani ich kombinacje w niczym nie pomagają, jednym lekarstwem jest restart serwera co jakiś czas. Wyczytałem tylko że w JRockit ten problem nie występuje ale tego raczej używał nie będę w najbliższym czasie.

Ktos się z tym spotkał, rozwiązał?
(Aplikacja spring, hibernate, wicket itd.)

https://issues.apache.org/jira/browse/WICKET-1959
http://drorbr.blogspot.com/2008/11/javalangoutofmemoryerror-permgen-space.html

W swojej aplikacji będziesz musiał wywołać
PropertyResolver.setClassCacheCreator(Application application, IClassCachCreator creator)
gdzie IClassCachCreator będzie zawsze zwracał jakiś obiekt, który implementuje Map, ale do którego nic nie można włożyć ("put" nic nie robi, przynajmniej dla klas Proxy).
Oczywiście to można zrobić tylko na środowisku developerskim (z przyczyn wydajnościowych).

ok, to chyba nie o to chodzi. Z tego co zrozumiałem cachowanie tych klas i obiektów proxy jest w trakcie działania app, znaczy jak coś już ta aplikacja robi na tych obiektach. Mój problem jest w tym, że wystarczy że wystartuje aplikację i będę robił sobie redeploy. Czyli wspomniana wyżej mapa jest cały czas pusta.
Efekt jest taki, że każdy kolejny redeploy (bądź restart pod jetty) zwiększa PermSpace o ~25mb.
Przypuszczam że problem to generowanie klas przez wspomniane frameworki, i liczba klas w cms perm gen stale rośnie i żadne gc tego nie rusza.

Mam podobny problem z serwerem GlassFish + Eclipse. Po kilkunastu redeployach aplikacji pojawia się błąd. Muszę wtedy ubić proces serwera w managerze zadań i ponownie uruchomić serwer. Zauważyłem też, że każdy deploy aplikacji trwa co raz dłużej. Zna ktoś rozwiązanie tego problemu?

starback napisał(a)

Mam podobny problem z serwerem GlassFish + Eclipse. Po kilkunastu redeployach aplikacji pojawia się błąd. Muszę wtedy ubić proces serwera w managerze zadań i ponownie uruchomić serwer. Zauważyłem też, że każdy deploy aplikacji trwa co raz dłużej. Zna ktoś rozwiązanie tego problemu?

Ja troche profilowalem ten problem w GlassFish (nie zwiazany z Eclipse, nie uzywam tej integracji, mamy standalone GF i JRebel, ale nasz serwer ciaglej integracji robi deploy kilka razy dziennie za pomoca mavena). Z tego co widzialem to jest memory leak GF: jak robisz deploy, startuje jakis watek ktory trzyma referencje do WebAppClassLoader, ktory z kolei trzyma wsystkie klasy aplikacji. Jak robisz undeploy, ten watek nie jest zabijany, ale trwa w najlepsze dalej. Po 10 redeployu masz juz 10 takich watkow, kazdy trzyma classloader ktory z kolei trzyma wszystkie klasy zaladowane podczas uzycia tej aplikacji. Po ktoryms razie (zaleznie od ustawienia Perm) po prostu kleka.
Wniosek - sprawdz Twoja aplikacje (polecam YourKit Profiler, droga bestia, ale wersja eval ma chyba 15 dni a problem zidentyfikujesz w pol dnia), i usun Twoje leaki. Zwieksz PermSpace. Nie rob tak czest redeployow (wylacz ten redeployment w eclipse, i zapoznaj sie z JRebel, piekne narzedzie, taki jakby super madry classloader ktory sam przeladowuje klasy bez redeployow aplikacji*). Naucz sie zyc z GlassFish i jego wadami :( ...

• Moj dzien wyglad tak, ze rano biore nowe zrodla (lub nie, zalezy ;d), buduje, robie deploy, i tyle. Zmieniam kod, a JRebel sam odkrywa ze zmienilem klasy i je przeladowuje, nie musze nic redeployowac. JRebel rowniez potrzebuje troche wiecej PermGen, ale jest to zdecydowany krok naprzod. JRebel dziala rowniez z tomcatem, i tam to juz bajka - PermSpace nie widzialem od dlugiego czasu.

problem dobrze wyjasnił poprzednik.
W swojej aplikacji zauważyłem trzy kwestie:
-nie wyłączałem ehcache przy undeployu
-zauważyłem też że sterowniki jdbc cały czas siedzą w pamięci po undeployu. Czyli podczas ubijania aplikacji, ręcznie odrejestrowuję sterownik do bazy
-uzywanie basicData Source jest złe, inne dataSource działają poprawnie (spring).

plus ustawienia jvma z początku wątku. No i teraz virtualne tomkaciki żyją po jakichś 30 redeployach.

przypuszczam że sam profiler może być ciężki - w pamięci siedzi cała aplikacja :)