Zwiększyłem limit pamięci Java Xmx, gdy został zgłoszony wyjątek związany z niewystarczającą ilością miejsca na sterty. Jednak obecnie doświadczam bardzo długi czas wykonania, które mogą być związane z pamięcią, ale nie widziałem wyjątku (jeszcze).Czy maszyna JVM zamienia stertę?
Zastanawiam się, co może stanowić długi czas realizacji. Czy JVM zamienia stertę na dysk?
Używam HotSpot 1.6.0 Aktualizacja 34.
JVM nie zamienia się na dysk, nie. System operacyjny może to zrobić. Możesz to wykryć, sprawdzając statystyki systemu operacyjnego.
Gdy w maszynie JVM kończy się pamięć, pobieranie śmieci jest uruchamiane coraz częściej. Każdy bieg powoduje zwolnienie mniejszej ilości pamięci, co dodatkowo zwiększa szybkość GC. W końcu dużo czasu spędza się w GC, co prawdopodobnie oznacza spowolnienie.
JVM nie czeka, aż zwolnione zostaną 0 bajtów, aby rzucić OutOfMemoryError. Rzeczywiście zrezygnuje, gdy GC po prostu zabiera zbyt dużo czasu w stosunku do liczby uwolnionych bajtów.
Możliwym skutkiem większej sterty jest wzrost w czasach GC - JVM musi analizować większą przestrzeń, więc trwa to dłużej - szczególnie, jeśli jego zatrzymanie świata GC.
Czy możesz odrobinę uzupełnić swoje pytanie?
Z jakiego sterty korzystasz? Jakie czasy widzisz? Jaki jest wzór użycia obiektów w twojej aplikacji? Na przykład kilka długowiecznych obiektów lub wiele krótkotrwałych obiektów.
Ustawiam Xmx na 2GB i jestem w trakcie próbowania z 3 GB. Wykonywanie pojedynczego wątku rzuciło wyjątek przestrzeni stosu z 2 GB. Uruchomiłem przez 15 minut z 3 GB i nie zostało to rzucone, ale nie wiem na pewno, czy 3 GB jest wystarczające, ponieważ całkowity czas wykonania wynosiłby setki godzin. Jeśli znak "highwater" prawdopodobnie zostanie trafiony o 15 minut, wydaje się, że warto użyć 3 GB jako limitu dla mojej siatki (9 węzłów). Będę miał 9 obiektów uruchomionych na 9 węzłach, mam nadzieję, że 1/9 czasu trwania. – H2ONaCl
Zamiana to zachowanie systemu operacyjnego, jak sądzę. – StarPinkER