>> Ok. After the server ran for more than 12 hours, the time spent on GC >> decreased from 11% to 3,4%, but 5 hours later it crashed.
All this 'black-hat' GC tuning and 'fast' object moving (especially objects accessing by some thread during GC-defragmentation) - try to use multithreaded load-stress tools (at least 100 requests in-parallel) and see that you need at least double memory if 12Gb is threshold for your FieldCache (largest objects) Also, don't trust this counters: >So I logged the Garbage Collection activity to check if it's because of >that. It seems like 11% of the time the application runs, it is stopped >because of GC. Stopped? Of course, locking/unlocking in order to move objects currently accessesd in multiuser-multithreaded Tomcat... you can easily create crash scenario proving that latest-greatest JVMs are buggy too. Don't forget: Tomcat is multithreaded, and if 'core' needs 10Gb in order to avoid OOM, you need to double it (in order to warm new cash instances on index replica / update). http://www.linkedin.com/in/liferay
