OutOfMemory Error

Opcje wymuszające utworzenie heap dumpa (.hprof) po wystąpieniu OutOfMemory:
- XX:+HeapDumpOnOutOfMemoryError
- XX:HeapDumpPath=[desired .hprof file location]

Plik .hprof można wygenerować na żądanie, programem jmap:
jmap -dump:file=[file name] [pid]

Plik przeanalizujemy np. Eclipse Memory Analyser-em (dostępnym jako wtyczka do eclipse oraz w wersji standalone).

Do podglądu działającej aplikacji można użyć narzędzia jvisualvm (lub jconsole), wchodzącego w skład JDK. Połączymy się zarówno z lokalnym procesem, jak i wirtualną maszyna działającą na innym serwerze (z pewnymi ograniczeniami).

Aby umożliwić zdalne połączenia do tomcata, dodajemy opcje:
-Dcom.sun.management.jmxremote.port=[np. 8086]
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

GC overhead limit exceeded

Błąd "java.lang.OutOfMemoryError : GC overhead limit exceeded" jest wyrzucany w sytuacji, gdy większość czasu (98%) poświęcana jest na odzyskiwanie pamięci, przy czym udaje się uzyskać mniej niż 2% sterty. Co jest w pełni uzasadnione - gdy zużycie dostępnej pamięci niebezpiecznie zbliża się do 100% i niewiele z tego daje się odzyskać - aplikacja potrafi dogorywać w nieskończoność.

Parametrami (ilością czasu oraz odzyskanej pamięci) można sterować poprzez opcje:
-XX:GCTimeLimit=[time limit]
-XX:GCHeapFreeLimit=[space limit]
Funkcjonalność można wyłączyć, dodając: -XX:-UseGCOverheadLimit.

Źródła:
GC Tuning (Excessive GC Time and OutOfMemoryError)
GC Ergonomics