完整的GC實時時間遠大於用戶的系統時間

我們有一個基於Web Java的應用程序，運行在JBoss上，允許的最大堆大小約爲1.2 GB（總計機器物理內存爲2 GB）。在某些時候，應用程序停止響應（對客戶端）幾分鐘。經過一番分析後，我們發現罪魁禍首是Full GC。下面是詳細GC日誌的摘錄：完整的GC實時時間遠大於用戶的系統時間

74477.402：[全GC [PSYoungGen：3648K-> 0K（332160K）] [PSOldGen：778476K-> 589497K（819200K）782124K-> 589497K（1151360K）[PSPermGen： 102671K-> 102671K（171328K）]，646.1546860秒] [時報：用戶= 3.84 SYS = 3.72，實際= 646.17秒]

什麼我不明白是怎麼回事可能是實時在Full GC上花費大約11分鐘（646秒），而用戶+系統時間僅爲7.5秒。 7.5秒的聲音給我更多合理的時間來清理<從老一代200 MB。其他時間去哪裏？

非常感謝。

來源

2010-06-15 Stas

所有其他時間去哪裏？

這很可能是您的應用程序導致虛擬內存抖動。基本上，您的應用程序需要更多的虛擬內存頁面，而不是可用於保存虛擬內存的物理頁面。因此，它花費大部分時間等待vm頁面被讀取和寫入光盤。

欲瞭解更多信息，請閱讀this wikipedia page。

治癒的方法是減少虛擬內存使用量或增加系統上的物理內存量。例如，您可以：在機器上

運行更少的應用程序，
減少Java應用程序堆大小，或
如果你是在一個虛擬的運行，增加物理內存的虛擬的分配。然而

（請注意，減少JVM堆的大小可以是一把雙刃劍。如果降低堆大小太多的應用程序無論是從OutOfMemoryError異常死亡，花費太多時間的垃圾收集，或不吃虧能夠有效地緩存事物。）

來源

2010-06-15 13:21:28

另一種方法可能是減少長壽命對象，因爲短壽命對象的回收速度會快得多。例如，對象池是Java中的一個不好的練習。 – 2010-06-15 13:40:11

是的。我專注於OP可以快速解決問題的事情。 – 2010-06-15 13:46:59

您確定嗎？我期望一個JVM進程等待一個頁面在sys =中花費時間。 – eckes 2012-05-02 16:55:43

完整的GC實時時間遠大於用戶的系統時間

回答

相關問題