GC爲降低1.2GB堆積了三個小時，可能是什麼原因？

Question

在我們的一臺服務器中，垃圾收集花費了近三個小時的時間來嘗試降低（成功）1.2GB的堆內存。從1.4GB到200MB。

在此期間，CPU使用率很高，幾乎達到80-100％。可能是什麼原因？假設沒有人對其進行任何更改，我們有4臺具有相同配置（JVM設置，服務器配置，硬件，網絡）的服務器，這可能是特定服務器運行3小時GC的原因。

對於每個GC活動，所有其他服務器只需要5到10分鐘。

請附上HP BAC圖形，以便您參考。顯示我想GC加入的時間，以及GC停止時的時間。

（斯蒂芬指出了更確鑿的結果）提供這些信息時，服務器管理員回來對我說：

• 的JVM的確切版本你 使用。 （標準Java SE 1.4.2）
• JVM選項。 （Coming）
• 的詳細信息的Web容器/服務器的基礎。 （Coming）
• 有關服務 的功能的信息。從 服務器/服務日誌文件任何相關線索的請求日誌（即將）
• 任何相關模式（即將）
• 的GC日誌中 事件的時間。 （如果您目前沒有啓用 GC日誌記錄，您可能需要 啓用它，等到問題 復發。）（即將）

Answer 1

你沒有提供太多的信息，但有可能原因可能是：

• 錯誤在您的應用程序;例如具有某些特殊特性的內存泄漏，或者內存不足並重新啓動的任務。

• 意外或故意拒絕服務攻擊;例如某些客戶端會不斷重試超大請求，並且每次都會減少「問題大小」。

• 具有某些特徵的一個極其長時間運行的請求。

• 眩暈 - 請參閱@Trent Gray-Donald的回答。 （如果你有過分的內存，那麼GC算法會涉及到大量頁面上隨機散佈的很多對象，這很可能會引起抖動，我不確定這會導致像你這樣的堆用量逐漸下降正在看。）

• JVM設置的病態組合。

• 您正在使用的特定JVM中的垃圾收集器中存在一個錯誤。上述的一些組合。

這是一種需要獲得Oracle/Java支持合同的問題。

---

以下信息可幫助診斷此：

• 您正在使用的JVM的確切版本。
• JVM選項。
• Web容器/服務器基礎的詳細信息。
• 有關服務的信息。
• 從服務器/服務日誌文件
• 任何有關模式的請求日誌
• 該事件時的GC日誌的任何相關線索。 （如果您目前還沒有啓用日誌記錄GC，您可能需要啓用它，等到問題再次出現。）

Answer 2

沒有太多的數據從這裏工作，但我的預感：你交換。我們唯一一次看到GC時代變得如此之高的時候，你已經過度使用了這個盒子，並且它正在分頁到磁盤。這可以將事情變成一個數量級（或更多）的性能下降。

您需要收集OS（以及可能的hypervisor，如果它適用）交換統計數據來證明或反駁這個理論。

（我知道CPU的時間比我預計的交換更高，但你永遠不知道。）

這也將是有益的，如果您發佈的硬件配置，「Java的版本」的信息，以及JVM命令行參數（例如：-Xmx和-Xms）來幫助縮小你真正運行的內容。