2015-03-20 22:29 GMT+02:00 Eric Robinson <eric.robin...@psmnv.com>: >> Very good information. I much prefer finding the actual root causes of >> things rather than just bumping the memory, but I'm not sure how much that >> would help because the best I can do is report the issue to the vendor. >> Changing the code is off the table for me. If we can zero in on a problem, >> we may be able to get them to fix it.
I think if you have vendor-locked app in vendor-locked environment (am I right?) - the bast way of fighting with OOMs will be looking into heaps. 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. 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. Threaddump on OOM is showing you what threads was not able to allocate some more memory in heap, and this may not be the thread which ate all memory. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
