Java进程（非堆）内存泄漏

Question

Issue Description: We are facing the following issue in a web application (on CQ5):

System Configurations details: • System memory: 7GB • Xmx: 3.5 GB • Xms: 1 GB • MaxPermGen: 300MB • Max no of observed threads: 620 (including 300 http request serving threads) • Xss: default

The issue is that the memory consumed by cq5 java process (which runs the servlet engine) keeps on increasing with time. Once it reaches above 6 to 6.5 GB (and system memory reaches 7 GB), the JVM stops responding. (due to shortage of memory and heavy paging activity). The heap and permgen however collectively remain at or below 3.8 (3.5+0.3) GB. This means that non heap memory (native memory + thread stack space) keeps growing from a few 100 MBs (after CQ5 server restart) to more than 2-3 GBs (after long runs 4-5 hrs with heavy loads). So our goal is basically to find out the memory leaks in non-heap memory which could be introduced due to 3rd party libraries, indirect references of Java code etc. We are not receiving any out of memory errors.

Help needed:

• Now most of the tools we used are giving us good information and details about heap memory. But we are unable to get a view to native memory. Request to provide your valuable suggestions on how to monitor non heap memory details (at object level or at memory area level).
• If anyone of you have faced a similar issue (non-heap memory leak) in any of your applications, and would like to share knowledge about how to fix non heap memory leaks, request you to share your experience.

Answer 1

This is really dependent on your specific implementation: what code you've deployed, what infrastructure you're using, what version you're running, what application servers (if any) you're using, etc.

That said, I have experienced memory leak issues with CQ5.5 and the Image Servlet. It's actually a memory leak down in one of the Java libraries that powers the Image Servlet, way down under the covers. It's remedied by a Java version update, but it's caused by the Image servlet. Kind of a long shot that it's your issue, but probably worth mentioning.