Dlaczego pamięć nie jest nigdy dostępna w mojej aplikacji Tomcat JRuby?

Question

Mam aplikację JRuby on Rails, która działa w Tomcat (Warble). Używa mostu Java, aby połączyć się z serwerem aplikacji Progress (OpenEdge) ... Kiedy monitoruję pamięć, ciągle rośnie.

• Tomcat 7,0
• JRuby 1.6.7.2 (Rubin-1.9.2-P312)
• JVM 1.7.0.25
• szyn 3.2.7
• jruby stelaża 1.1.7
• warbler 1.3.6

Jaki jest najlepszy sposób, aby dojść do sedna problemu? Sądzę, że mogą to być obiekty JRuby, które nie zostały oczyszczone, lub coś w mostku Java lub Garbagerze, który nie wykonuje swojej pracy ...

Nawet jeśli pozwolę, aby proces trwał pół godziny , pamięć nie znika ...

• Czy istnieje sposób na sprawdzenie, które Obiekty są żywe?
• Czy są dostępne bezpłatne narzędzia, dzięki którym mogę uzyskać więcej informacji o tym, kto używa całej pamięci?

Nawiasem mówiąc, mam już skonfigurowany serwer Tomcat do korzystania z większej ilości pamięci, ale to tylko opóźnia się błąd przestrzeń sterty ...

EDIT: Co ja faktycznie widząc, że używa tylko Tomcat cała pamięć, którą może maksymalnie wykorzystać (maksymalna ilość pamięci). I nigdy go nie uwalnia. Może to po prostu normalne zachowanie ... Ustawiłem teraz na maksimum 256 MB, aw Menedżerze zadań pamięć pozostaje na poziomie około 256 MB.

EDIT:

Podczas tworzenia zrzutu sterty i pozwalając zaćmienie analizować go z Eclipse Memory Analyzer to jest raport Dostaję. Myślę, że to normalne, gdyż narzędzie prawdopodobnie nie spodziewa się całą historię JRuby ...

Problem Suspect 1

6,458 przypadki „org.jruby.RubyClass”, ładowane przez „org.apache. catalina.loader.WebappClassLoader @ 0x700ec6988 "zajmują 56.969.616 (31,78%) bajtów.

Słowa kluczowe org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 org.jruby.RubyClass

Problem Suspect 2

10,597 przypadki „org.jruby.internal.runtime.methods. DefaultMethod ", ładowane przez" org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 "zajmują 22.182.112 (12,37%) bajtów.

Słowa kluczowe org.jruby.internal.runtime.methods.DefaultMethod org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988

problem podejrzanego 3

3.144 przypadkach "org.jruby.RubyModule", obciążonego "org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988" zajmują 21.226.816 (11,84 %) bajtów.

słowa kluczowe org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 org.jruby.RubyModule

problem podejrzanego 4

8,888 powtórzenia "org.jruby.MetaClass", załadowanych przez " org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 "zajmują 18.563.784 (10,35%) bajtów.

Słowa kluczowe org.jruby.MetaClass org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988

Answer 1

to pachnie trochę jak wycieku pamięci. Niezły widok.

Jeśli nie ma dużo kodu, najpierw sprawdź, czy zamykasz połączenia i strumienie oraz wszystkie obiekty, które mają metodę close. Jeśli ten problem pojawił się ostatnio, spójrz na kod, który został ostatnio zmodyfikowany.

Inną rzeczą, którą chciałbym spróbować jest inspekcja kodu z some tool.

Może napisać kilka testów, aby przyspieszyć wyciek (np. Generowanie żądań), następnie możesz spróbować wyłączyć kod z aplikacji, aż znajdziesz obszar, który powoduje wyciek.

Nie polecam sprawdzania obiektów w pamięci, ponieważ jest to powolny i bolesny proces.

Answer 2

Po pierwsze: 256M Heap Space nie jest dużo dla aplikacji Java - zwłaszcza, że ​​w pełni rozwinięty serwer kontenera/aplikacji serwletów jest zaangażowany i (prawdopodobnie) wiele bibliotek.

Java zazwyczaj nie przekazuje pamięci z powrotem do systemu operacyjnego - po przydzieleniu pamięci jest ona uważana za własność JVM. Sądzę, że mogą istnieć pewne implementacje zarządzania pamięcią, które wstrzymują pamięć, ale nigdy ich nie widziałem. Moim typowym zaleceniem w środowiskach produkcyjnych jest posiadanie - Xmx równe -Xms mimo to (przydzielić całą pamięć, którą JVM ma od razu przeznaczyć)

Kończy się przestrzeń sterty to sygnał dla jednego z dwóch (lub więcej)) warunki: a) Masz aplikację z wyciekiem pamięci, b) nie przeznaczasz wystarczającej ilości na żądanie aplikacji.

Zwiększ alokację pamięci dla JVM i monitoruj użycie pamięci i usuwanie śmieci, aby wykluczyć b) - jeśli możesz bezpiecznie powiedzieć, że twoja aplikacja ma wystarczającą ilość pamięci dla swoich potrzeb, poluj na a) i znajdź główną przyczynę wyciek pamięci. Najlepiej użyj do tego profilera, ale z 256M pamięci, istnieje duża szansa, że ​​masz za mało pamięci.