這個文章與 Oracle 的 Hotspot JVM 虛擬機器的記憶體管理為參照的。這些建議是我們在對大的 Confluence 安裝例項使用者進行諮詢服務的時候得到的最佳配置方案。

請不要在 Confluence 中使用 Concurrent Mark Sweep (CMS) ，除非你得到了 Atlassian 支援小組的明確說明。這個需要額外的手工調整和測試，通常這個會降低系統的效能。

使用一個小的 heap

在不出現 OutOfMemory 錯誤的情況下，保持你的 heap 儘可能的小。當你遇到了 OutOfMemory 錯誤，需要增加 heap 的時候，我們推薦你按照 512MB 到 1 GB 的順序進行增加。如果你還持續的獲得 OutOfMemory 錯誤，那麼你可以考慮再繼續增加 512 MB 或者 1GB。你可以持續進行增加，直到你不再出現 OutOfMemory 錯誤。不要嘗試一次增加到位，這樣可能會導致垃圾收集時間的增長。

刪除所有老的收集引數

只有在完全的 GC 後，JVM 將會重新定義 Eden, Survivor 等引數的大小，這個大小是基於 GC 處理來確定的。這個將會保證 GC 處理程式能夠處理真實的垃圾情況和垃圾物件。在絕大部分情況下，能夠保證 JVM 為你提供更好的效能。

如果你的 JVM 中添加了引數，當在垃圾收集的時候遇到了困難。那麼我們建議你刪除掉你在 GC 前新增的引數，除非你新增的這些引數是為了解決一些特定的問題。你現在應該考慮如何避免在 GC 中出現的問題，而不是導致其他的問題。

檢查你的虛擬機器（VM）資源

如果你執行 Confluence 在一個 VM 上的話，檢查這個 VM 沒有使用 swap 檔案。

如果這個 VM 了使用了 swap 檔案，那麼當 JVM 進行垃圾收集的時候，將會把這些 swap 檔案載入到記憶體後清理他們，這個將會導致垃圾清理程序的長時間暫停。為了避免使用 swapping, ballooning 和 bursting，將這些資訊載入到 VM 的記憶體中。

手動清理

如果你按照上面的說明進行了操作後還遇到了一些困難，但是你還是希望能夠提高系統的效能，我們推薦你使用Garbage Collection (GC) Tuning Guide 頁面提供的方法。這個頁面將會知道你如何達到你自己期望的效能指標（throughput/footprint/latency）和如何進行調整。

檢視你的垃圾收集日誌