Tomcat na serwerze produkcyjnym, PermGen i redeploys

Question

to wygląda

MemoryError: PermGen space 
java.lang.OutOfMemoryError: PermGen space 

jest częstym problemem. Możesz zwiększyć rozmiar swojego wolnego miejsca, ale po 100 lub 200 odsłonach będzie on pełny. Śledzenie wycieków pamięci ClassLoader jest prawie niemożliwe.

Jakie są twoje metody dla Tomcat (lub innego prostego kontenera serwletów - Jetty?) Na serwerze produkcyjnym? Czy serwer jest restartowany po każdym wdrożeniu rozwiązania?

Czy używasz jednego Tomcat do wielu zastosowań?

Może powinienem używać wielu serwerów Jetty na różnych portach (lub wbudowanym pomoście) i za każdym razem cofać/restartować/wdrażać?

Answer 1

Zrezygnowałem z używania menedżera tomcat i teraz zawsze zamykam tomcat, aby ponownie wdrożyć.

Uruchomimy dwa koty na tym samym serwerze i używamy serwera WWW apache z mod_proxy_ajp, aby użytkownicy mieli dostęp do obu aplikacji przez ten sam port 80. Jest to miłe również dlatego, że użytkownicy widzą stronę Usługa niedostępna dla Apache, gdy kocioł jest wyłączony.

Answer 2

Tak, rzeczywiście, jest to problem. Prowadzimy trzy aplikacje internetowe na serwerze Tomcat: nr 1 korzysta ze struktury aplikacji internetowych, Hibernate i wielu innych JAR-ów, nie. 2 używa Hibernate i kilku JARów i nie. 3 to w zasadzie bardzo prosta aplikacja JSP.

Kiedy wdrażamy nie. 1, zawsze restartujemy Tomcat. W przeciwnym razie błąd miejsca PermGen wkrótce nas ugryzie. Nr 2 może czasami być wdrożony bez problemu, ale ponieważ często zmienia się, gdy nie. 1 również, i tak zaplanowano restart. Nr 3 nie stanowi żadnego problemu i może być wdrożony tak często, jak jest to konieczne, bez problemu.

Tak, tak, zazwyczaj restartujemy Tomcat. Ale czekamy również na Tomcat 7, który ma obsłużyć wiele problemów związanych z ładowarką pamięci/klas, które są pochowane w różnych JAR i frameworkach innych firm.

Answer 3

Można spróbować dodać te opcje Java:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled 

Umożliwia to zbieranie śmieci w przestrzeni PermGen (domyślnie wyłączone) i pozwala na GC do rozładunku klas. Dodatkowo powinieneś użyć -XX: PermSize = 64m -XX: MaxPermSize = 128m wspomnianych gdzie indziej, aby zwiększyć ilość dostępnego PermGena.

Answer 4

Powinieneś włączyć PermGen garbage collection. Domyślnie maszyna wirtualna Hotspot NIE zbiera śmieci PermGen, co oznacza, że ​​wszystkie wczytane pliki klas pozostają w pamięci na zawsze. Każde nowe wdrożenie ładuje nowy zestaw plików klas, co oznacza, że ​​w końcu zabraknie przestrzeni PermGen.

Answer 5

Przełączniki PermGen w HotSpot tylko opóźniają problem, a ostatecznie i tak otrzymasz OutOfMemoryError.

Mamy ten problem przez długi czas, a jedynym rozwiązaniem, które znalazłem do tej pory, jest użycie JRockit. Nie ma PermGenu, więc problem po prostu znika. Oceniamy to teraz na naszych serwerach testowych i od czasu przełączenia nie mieliśmy żadnego problemu PermGen. Próbowałem też powtórzyć więcej niż 20 razy na mojej lokalnej maszynie z aplikacją, która otrzymała ten błąd podczas pierwszej redepozycji i wszystko pięknie się potoczyło.

JRockit ma być zintegrowany z OpenJDK, więc być może ten problem zniknie również w przypadku Java w przyszłości.

http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html

I to za darmo, w ramach tej samej licencji jak HotSpot:

https://blogs.oracle.com/henrik/entry/jrockit_is_now_free_and

Answer 6

Która wersja Tomcat używasz? Tomcat 7 i 6.0.30 mają wiele funkcji pozwalających uniknąć tych wycieków lub przynajmniej ostrzegają o ich przyczynie.

This presentation autorstwa Marka Thomasa z SpringSource (i długoletniego uczestnika Tomkata) w tej sprawie jest bardzo interesująca.

Answer 7

Odsyłaczem jest nowa wersja narzędzia Plumbr, która może monitorować i wykrywać przecieki w Generacyjnej Generacji.