apache，tomcat，mod_jk和mysql导致内存泄漏

Question

我正在具有2GB RAM的debian-lenny x64服​​务器上使用apache 2.2和mod_jk 1.2.26运行tomcat 7。
我的服务器出现一个奇怪的问题：每隔几个小时，有时（在负载下）每隔几分钟，我的tomcat ajp-connector会因内存泄漏错误而暂停，但似乎此错误也会影响系统的其他部分（例如其他部分）正在运行的应用程序也会停止工作），我必须重新启动服务器才能解决该问题。
我已经检查了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检查了内存使用情况。 wanderfull的观点是，当服务器发生故障时，在堆和非堆jvm内存空间上都会显示大量可用内存。 如前所述，在服务器崩溃后，许多其他应用程序也会失败，而当我想重新启动它们时，它会发出资源临时不可用的消息（我也检查了limits.conf文件）。
所以我真的很困惑这个严重的问题很多天了，我真的对此一无所知。 因此，有人可以给我任何建议来解决这个复杂而未知的问题吗？
此错误的最可能原因是什么？

Answer 1

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

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

另外，为您要用于启动它的用户检查相同的内容（例如，如果您没有人使用您的东西，请运行su -c“ ulimit -a” -s / bin / sh没人查看它的实际作用）用户视为限制）。 那应该向您显示一个问题（几天前就已经出现了，完全错过了检查）。

在这种情况开始发生的那一刻，您还可以使用“ ps -eLf | wc -l”为该用户计算所有正在运行的线程和进程（甚至更好地使用rrdtool或其他工具对其进行监视），这将使您更简单系统上运行的所有进程和线程的数量。 此信息，以及对所有特定用户的限制，应该可以解决您的问题。

Answer 2

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

如果看到锯齿模式，请在锯齿的峰值附近进行堆转储，否则，请在jvm运行了足够长的时间后进行堆转储，以免发生高风险和OOM错误。 然后将该.hprof文件复制到另一台机器上，并使用Eclipse MAT（内存分析工具）将其打开并找出可能的罪魁祸首。 您仍然需要花一些时间来关注数据结构中的引用，还需要阅读一些Javadocs来弄清楚正在使用的Hashmap或List失去了控制。 排序选项还有助于将精力集中在最可能出现问题的区域。

没有简单的答案。

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

Answer 3

我终于找到了问题：这实际上不是内存泄漏，但是导致了VPS允许线程数的限制。 我的服务器是Xen vps，默认限制为256个线程，因此当达到最大允许线程数时，主管将杀死一些正在运行的线程（这是停止某些正在运行的进程的原因）。 通过将允许的线程数增加到512，问题得以完全解决（当然，如果我在tomcat设置中增加maxThreads，显然问题将再次出现）。