這篇文章是關于最近的性能調(diào)整練習的。 與往常一樣，這些開始于關于癥狀的模糊表述。 這次，魔鬼采取了“應用程序速度慢，我們無法訪問源代碼的形式。 我們有什么改善情況的選擇”。

對該應用程序進行仔細研究后發(fā)現(xiàn)，它由捆綁在一起的幾個批處理作業(yè)組成。 深入研究“績效”標準表明，執(zhí)行特定工作所花費的時間過長。 稍后再仔細檢查，我得到了一個可衡量的目標。 我需要從特定的作業(yè)運行時間中抽出兩分鐘，以適應預先分配的時間窗口。

陷入困境的應用程序是一個看起來非常無辜的小型JAR文件。 幸運的是，這也捆綁了負載測試。

在打開GC日志記錄的情況下運行該應用程序（ -XX：+ PrintGCTimeStamps -Xloggc：/path-to/gc.log -XX：+ PrintGCDetails ）并快速查看日志，這是優(yōu)化的第一個目標。 累積的GC暫停時間總計為三分半鐘，暗示我可能會有機會。

在這種情況下，他可以使用幾種工具，其中一些簡單明了：

• 修改堆/ permgen的大小
• 更改GC算法
• 配置內(nèi)存區(qū)域之間的比率

我采取了改變堆大小的方法。 除了幸運的猜測外，它還基于最近學到的有關實時數(shù)據(jù)集大小和建議堆大小之間的相關性的課程。 從GC日志中，我還注意到該應用程序的實時數(shù)據(jù)集約為240m。 因此，根據(jù)我最近獲得的知識，此應用程序堆的最佳結合點在720至960m之間。

但是在配置中，我發(fā)現(xiàn)-Xmx設置為僅300m。 稍微調(diào)整一下參數(shù)，我再次運行測試，結果如下：

堆大小 總GC暫停時間 通量

300m	207.48秒	92.25％
384m	54.13秒	97.97％
720m	20.52秒	99.11％
1,440m	* 11.37秒	* 99.55％

*表示此配置在運行期間未觸發(fā)Full GC。

現(xiàn)在，如果您查看結果，可能會將結果轉換為“越大越好”。 如果僅以毫秒為單位進行測量，那的確是正確的。 如果成功標準之一與金錢有關，那么可能就不那么容易了。 在大型部署中將數(shù)百或數(shù)千臺這些機器放在一起，您可能會單單在電費賬單上就感到討厭。

除此之外，本文是性能調(diào)優(yōu)教科書中的教科書案例。 如果您有可衡量的目標，并且可以衡量結果而不是猜測，那么您將成功。 如果我被迫在沒有明確目標或負載測試能力的情況下跳入，那么我仍然會調(diào)整配置的隨機位。

參考： 為JVM分配內(nèi)存：來自我們的JCG合作伙伴 Nikita Salnikov Tarnovski （來自Plumbr Blog博客） 的案例研究 。

翻譯自: https://www.javacodegeeks.com/2014/03/allocating-memory-for-the-jvm-a-case-study.html

總結

以上是生活随笔為你收集整理的为JVM分配内存：一个案例研究的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。