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，顯然問題將再次出現）。