jvm默認的初始化參數(shù)

如今，JVM被認為是智能的。 預(yù)期配置不多-只需設(shè)置要在啟動腳本中使用的最大堆，您就可以進行了。 所有其他默認設(shè)置都很好。 大概我們當中有些人誤以為。 實際上，在運行時期間發(fā)生了很多事情，無法自動調(diào)整性能，因此，在我最近遇到的一個案例研究中，我將帶您逐步了解哪些內(nèi)容以及何時進行調(diào)整。

但是在討論案例本身之前，先介紹了有關(guān)JVM內(nèi)部的一些背景知識。 以下所有內(nèi)容與Oracle Hotspot 7有關(guān)。 其他供應(yīng)商或Hotspot JVM的較早版本很可能附帶不同的默認值。

JVM默認選項

第一站 ：JVM嘗試確定是否 它正在客戶端環(huán)境的服務(wù)器上運行。 它通過研究體系結(jié)構(gòu)和OS組合來做到這一點。 簡單總結(jié)：

建筑	CPU /內(nèi)存	操作系統(tǒng)	默認
i586	任何	微軟視窗	客戶
AMD64	任何	任何	服務(wù)器
64位SPARC	任何	的Solaris	服務(wù)器
32位SPARC	2個以上內(nèi)核和> 2GB RAM	的Solaris	服務(wù)器
32位SPARC	1核或<2GB RAM	的Solaris	客戶
i568	2個以上內(nèi)核和> 2GB RAM	Linux或Solaris	服務(wù)器
i568	1核或<2GB RAM	Linux或Solaris	客戶

例如，如果您在32位Linux上的Amazone EC2 m1.medium實例上運行，則默認情況下，您將被視為在客戶端計算機上運行。

這很重要，因為JVM在客戶端和服務(wù)器上的優(yōu)化方式完全不同-在客戶端計算機上，它試圖減少啟動時間，并在啟動過程中跳過一些優(yōu)化。 在服務(wù)器環(huán)境上，為了節(jié)省以后的吞吐量，會犧牲一些啟動時間。

第二組默認值 ：堆大小。 如果您的環(huán)境被認為是根據(jù)先前準則確定的服務(wù)器，則分配的初始堆將是計算機上可用內(nèi)存的1/64。 在4G機器上，這意味著您的初始堆大小將為64MB。 如果在極低的內(nèi)存條件下（<1GB）運行，它可能會更小，但是在這種情況下，我將嚴重懷疑您在做任何合理的事情。 在這個千年中，還沒有看到內(nèi)存少于千兆字節(jié)的服務(wù)器。 如果有的話，我會提醒您，如今1 GB的DDR成本不到20美元……

但這將是初始堆大小。 最大堆大小將是可用總內(nèi)存的?或1GB中的最小值。 因此，在我們的1.7GB Amazon EC2 m1.small實例中，可用于JVM的最大堆大小約為435MB。

下一步 ：使用默認垃圾收集器。 如果認為您正在客戶端JVM上運行，則JVM所應(yīng)用的默認值為串行GC（ -XX：+ UseSerialGC ）。 在服務(wù)器級計算機上（同樣，請參見第一部分），默認值為并行GC（ -XX：+ UseParallelGC ）。

默認值還有很多其他事情，例如PermGen的大小，不同的世代調(diào)整，GC暫停限制等。但是為了保持帖子的大小在受控范圍內(nèi)，請堅持使用上述配置。 對于好奇的用戶-您可以從以下材料中進一步了解默認值：

• http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
• http://docs.oracle.com/javase/7/docs/technotes/guides/vm/gc-ergonomics.html
• http://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html

案例分析

現(xiàn)在讓我們看一下案例研究的行為。 以及我們是否應(yīng)該憑借決策信任JVM還是跳入我們自己。

我們手頭的應(yīng)用程序是一個問題跟蹤器。 即JIRA 。 這是一個在后端具有關(guān)系數(shù)據(jù)庫的Web應(yīng)用程序。 部署在Tomcat上。 在我們的一種客戶端環(huán)境中表現(xiàn)不佳。 并不是由于任何泄漏，而是由于部署中的不同配置問題。 由于GC暫停時間特別長，這種行為不當?shù)呐渲脤?dǎo)致吞吐量和延遲方面的重大損失。 我們設(shè)法幫助了客戶，但是出于隱私考慮，我們將不在此處介紹確切的詳細信息。 但是案例很好，因此我們繼續(xù)自己下載JIRA ，以演示我們從此實際案例研究中發(fā)現(xiàn)的一些概念。

Atlassian的特別好之處在于，他們附帶了一些打包好的負載測試 。 因此，我們有一個基準可用于我們的配置。

我們仔細拆箱了我們新收購的JIRA，并將其安裝在64位Linux Amazon EC2 m1.medium實例上。 并運行捆綁測試 。 無需更改默認值。 Atlassian小組將其設(shè)置為-Xms256m -Xmx768m -XX：MaxPermSize = 256m

在每次運行期間，我們使用-XX：+ PrintGCTimeStamps -Xloggc：/tmp/gc.log -XX：+ PrintGCDetails收集了GC日志，并在GCViewer的幫助下分析了此統(tǒng)計信息。

結(jié)果實際上還不錯。 我們將測試運行了一個小時，然后由于垃圾收集暫停而損失了僅151秒 。 占總運行時間的4.2％。 在最壞的情況下，gc的暫停時間為2秒 。 因此，GC暫停會影響此特定應(yīng)用程序的吞吐量和延遲。 但是不要太多。 但是足以作為本案例研究的基準–在我們的實際客戶中，GC暫停時間長達25秒。

挖掘GC日志顯示了一個直接的問題。 Full GC的大多數(shù)運行都是由PermGen大小隨時間擴展而引起的。 日志顯示，測試期間總共使用了大約155MB的PermGen。 因此，通過在啟動腳本中添加-XX：PermSize = 170m ，我們將PermGen的初始大小增加到比實際使用的大小更多。 這使總的暫停時間從151秒減少到134秒 。 并將最大延遲從2,000ms降低到1300ms 。

然后我們發(fā)現(xiàn)了完全出乎意料的事情。 我們的JVM使用的GC實際上是串行GC。 如果您認真遵循了我們的文章，則情況并非如此-64位Linux機器應(yīng)始終被視為服務(wù)器級機器，并且所使用的GC應(yīng)該是并行GC。 但顯然并非如此。 到目前為止，我們最好的猜測是–即使JVM以服務(wù)器模式啟動，它仍然會根據(jù)可用的內(nèi)存和內(nèi)核來選擇所使用的GC。 由于此m1.medium實例具有3.75GB內(nèi)存，但只有一個虛擬內(nèi)核，因此所選的GC仍是串行的。 但是，如果你們對這個話題有更多的見解，我們渴望找到更多。

盡管如此，我們將算法更改為-XX：+ UseParallelGC并重新運行測試。 結(jié)果–累積的停頓進一步減少到92秒 。 最壞情況的延遲也減少到了1200ms 。

對于最終測試，我們嘗試嘗試并發(fā)標記和掃描模式。 但是該算法對我們完全失敗了–暫停時間增加到300秒，延遲增加到5,000毫秒以上。 在這里，我們放棄了，決定叫它一個晚上。

因此，僅使用兩個JVM啟動參數(shù)并花費幾個小時來配置和解釋結(jié)果，我們就有效地提高了應(yīng)用程序的吞吐量和延遲。 絕對數(shù)字聽起來并不令人印象深刻– GC暫停從151秒減少到92秒，最壞情況的延遲從2,000ms減少到1200ms ，但是請記住，這只是一個只有兩個配置設(shè)置的小測試。 從％的角度來看–嘿，我們都提高了與GC暫停相關(guān)的吞吐量，并將延遲減少了40％ ！

無論如何–我們現(xiàn)在再有一個案例向您展示–性能調(diào)整就是關(guān)于設(shè)定目標，進行測量，調(diào)整和再次測量。 也許您和我們一樣幸運，只需更改兩個配置選項就可以使您的用戶更快樂40％……

參考： 您是否應(yīng)該信任JVM中的默認設(shè)置？ 由我們的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上獲得。

翻譯自: https://www.javacodegeeks.com/2012/12/should-you-trust-the-default-settings-in-jvm.html

jvm默認的初始化參數(shù)

總結(jié)

以上是生活随笔為你收集整理的jvm默认的初始化参数_您是否应该信任JVM中的默认设置？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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