// I think if you have vendor-locked app in vendor-locked environment (am I right?) //
Yes indeed. // As I said above, there is an options for JVM: -XX:-HeapDumpOnOutOfMemoryError - it will make heapdump on OOM. -XX:HeapDumpPath=./java_pid<pid>.hprof - give it an reasonable path to file. Set this options to JVM, and it will make heapdumps automatically. // Will these heap dumps be the same size as the current tomcat memory utilization? // After you got an heapdump - you can look for biggest object in it, or give it to a vendor. What you are doind now - is a temperature measurement using something, that's not measure temperature. You are collect threaddump, but it's a "where it was"-state of app, but not "what was in it"-state. Imagine that something already occupies some size in memory. And some thread doing it's small job and tries to allocate a little size of memory. A small size, but there is no more free memory for allocation - this is a reason of OOM. From heapdump you can look what it was. // That sounds extremely promising. Now I'm starting to get excited. --Eric
