apache、tomcat、mod_jk和mysql的内存泄漏

Question

我在一个内存为2 2GB的debian-lenny x64服务器上运行Tomcat7和Apache2.2& mod_jk 1.2.26。

我的服务器有一个奇怪的问题:每隔几个小时&有时(在负载下)每隔几分钟，我的tomcat ajp连接器会因为内存泄漏错误而暂停，但这个错误似乎也会影响系统的其他部分(例如，一些其他正在运行的应用程序也停止工作)&我必须重新启动服务器来解决这个问题一段时间。

我已经检查了catalina.out好几天了，但似乎在暂停ajp之前没有一个独特的错误模式，并显示了以下消息：

INFO: Pausing ProtocolHandler ["ajp-bio-8009"]

有时在暂停前会出现以下消息：

Exception in thread "ajp-bio-8009-Acceptor-0" java.lang.OutOfMemoryError: unable to create new native thread
    at java.lang.Thread.start0(Native Method)
    at java.lang.Thread.start(Thread.java:597)...

有时是这样的：

INFO: Reloading Context with name [] has started
Exception in thread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" java.lang.OutOfMemoryError: unable to create new native thread
    at java.lang.Thread.start0(Native Method)
    at java.lang.Thread.start(Thread.java:597)
    at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5482)
    at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:230)
    at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3847)
    at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:424)
    at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1214)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1400)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1410)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1410)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1389)
    at java.lang.Thread.run(Thread.java:619)
java.sql.SQLException: null,  message from server: "Can't create a new thread (errno 11); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug"...

另一些时候，输出消息与程序的某些其他部分相关。

我已经检查了我的应用程序源代码&我不认为是它导致了问题，我还使用jConsole检查了内存使用情况。最重要的是，当服务器出现故障时，它会在堆和非堆jvm内存空间上显示大量空闲内存。如前所述，在服务器崩溃后，许多其他应用程序也会失败&当我想重新启动它们时，它会给出一条资源临时不可用的消息(我还检查了我的limits.conf文件)。

所以很多天我真的真的对这个严重的问题感到困惑&我真的对它一无所知。那么，有没有人能给我一些建议来解决这个复杂而又未知的问题呢？

导致此错误的最可能原因是什么？

Answer 1

我最终发现了问题:这实际上不是内存泄漏，但VPS允许的线程数量限制导致了问题。我的服务器是Xen vps，默认限制为256个线程，所以当它达到允许的最大线程数时，supervisor会终止一些正在运行的线程(这就是停止我的一些正在运行的进程的原因)。通过将允许的线程数增加到512，问题就完全解决了(当然，如果我在tomcat设置中增加maxThreads，问题显然会再次出现)。

Answer 2

您对进程数量的限制是多少？

使用uname -a检查它们，并检查最大进程数。如果是1024，则增加它。

另外，检查您用来启动它的用户的相同设置(例如，如果您的应用程序使用无人用户，请运行su -c "ulimit -a“-s /bin/sh nobody来查看此用户实际看到的限制)。这应该会告诉你一个问题(几天前就有了，完全错过了检查这个)。

在这种情况开始发生的那一刻，您还可以使用"ps -eLf | wc -l“为该用户计算所有正在运行的线程和进程(或者使用rrdtool或其他工具监视它更好)，这将返回系统上正在运行的所有进程和线程的简单计数。这些信息，再加上对所有特定用户的限制，应该可以解决您的问题。

Answer 3

使用jvisualvm检查jvm的堆使用情况。如果您看到它在一段时间内缓慢攀升，那就是内存泄漏。有时内存泄漏是短期的，最终会被清除，然后又会重新开始。

如果您看到一种锯齿模式，请在锯齿模式的峰值附近进行堆转储，否则在jvm运行足够长的时间后进行堆转储，这会有很高的发生和OOM错误的风险。然后将该.hprof文件复制到另一台机器上，并使用Eclipse MAT (内存分析工具)打开它并识别可能的罪魁祸首。您仍然需要花费一些时间来跟踪数据结构中的引用，并读取一些Javadoc，以找出到底是什么在使用该Hashmap或列表，这些列表正在失控地增长。排序选项对于关注最有可能出现问题的区域也很有用。

没有简单的答案。

请注意，SUN jvm中还包含一个命令行工具，可以触发堆转储。如果您有一个好的分析器，这也是有用的，因为内存泄漏通常存在于频繁执行的代码中，因此将显示为分析器中的一个热点。