隨機的時間后，JVM性能下降

Question

簡而言之，我遇到了一個性能問題，即一次“隨機”出現在1個JVM中，而這可能已經運行了好幾天，但似乎無法找到根本原因。 我傾向於在吞噬線程池中消耗一些東西，但一直未能找到答案。

我已經遍歷了所有可以想到的內容，任何建議都很棒！

（我可以使用Jprofiler，yourkit和jvisualvm，並且我嘗試了全部使用它們並在JVM中運行比較）

所以這是設置。 我們在一個頻繁使用的測試環境中運行40個JVM（每台硬件機器10個）。 他們使用一種稱為UltraESB（2.3.0）的開源產品，該產品利用線程池進行異步請求/答復處理，但在我們的情況下是基於無狀態標頭的JMS消息路由。 在我們的開發環境中，我們的設置較少，但仍然很常用，我們從未見過此問題。

因此，我們看到非常頻繁的次要GC（每隔幾分鍾一次），而很少見到主要GC（一天左右一次）。 我們在centos 6.7上使用熱點Java 1.7_71（已修復Haswell CPU錯誤）

有時（在我看來，這完全是隨機的），其中一個JVM的性能將開始下降（我們有針對應用程序性能的監視器+指標）。 通常情況下，我們會在1毫秒內處理一條消息。 一旦遇到錯誤情況，我們開始看到數百（100-200）毫秒的處理時間。 在幾周內運行這些程序時，我們將看到幾個性能不佳的JVM。 回收會清理掉東西，並且幾天之內它們就會運轉良好。 隨着JVM錯誤的出現，我們開始看到它們與遇到性能問題的其他實例（包括其他硬件上的實例）的處理時間幾乎完全相同。 這並不奇怪，因為它們是完全相同的代碼庫和JMS負載均衡循環機制，因此它們處理幾乎相同數量的消息。

我通過打開CPU性能分析來觸發此性能影響。 如圖所示： 藍色是一個很好的過程，直到我打開CPU跟蹤並且它開始表現不佳為止

有趣的是，即使禁用了性能分析后，性能仍然持續不佳。

我嘗試測量的東西

我嘗試過的所有方法都沒有將我引向任何銀彈。

GC監視 -參考和性能不佳的JVM之間的GC持續時間和CPU利用率似乎保持一致。

GC啟動選項：

GC_OPTS="-XX:+PrintGCDetails \
-XX:+UseG1GC \
-XX:MaxGCPauseMillis=100 \
-XX:+ParallelRefProcEnabled \
-XX:+UnlockExperimentalVMOptions \
-XX:-ResizePLAB \
-XX:G1NewSizePercent=50 \
-XX:G1MaxNewSizePercent=50 \
-XX:+PrintAdaptiveSizePolicy \
-Xloggc:/logs/applogs/${instancename}/gc.${DATE}.log"

CPU采樣 JVM內部發生了很多事情，沒有什么對我有所作為。 啟用此選項會引起問題，但並不總是取決於采樣設置。

線程池使用情況 Stats作為MBean導出，並且線程池 （春季3.2.4 ThreadPoolTask​​Executor）和使用中的線程似乎與其他性能良好的實例相同。

Answer 1

您可以嘗試http://mevss.jku.at/AntTracks 。 它是一個研究JVM，記錄您的內存行為。 然后，它可以顯示一段時間內的堆屬性，還可以基於跟蹤在任何時間離線顯示堆。 該VM的構建對行為的影響極小，因此不會像配置錯誤的采樣所造成的那樣扭曲應用程序行為。 當然，這僅在您希望內存/ GC在您的問題中起作用的情況下才有用。

Answer 2

當我們從Spring DMLC偵聽器容器使用的線程池中拆分工作線程池時，我們的問題消失了。 仍然無法找到根本原因，但問題已解決。