jvm-內存大小設置簡述 -讀《java-performance》

時間 2019-11-13

標籤 jvm 內存大小設置簡述 java performance 欄目 Java 简体版

原文原文鏈接

Java Performance》做者 Charlie Hunt / Binu John 介紹

Charlie Hunt 現任Salesforce公司的性能工程架構師。曾任Oracle公司首席JVM性能工程師，負責HotSpot Java虛擬機和Java SE類庫性能的改進。Charlie擁有美國伊利諾伊理工大學的計算機科學碩士學位、愛荷華州立大學的計算機科學學士學位。
Binu John 是世界上最大的社交網站建立平臺Ning.com的高級性能工程師。他目前的職責是着力改善Ning平臺的性能和擴展性，以支持每個月數百萬PV的訪問量。Binu擁有美國愛荷華大學生物醫學工程和計算機科學碩士學位。架構

書中jvm推薦配置片斷

一、計算存活對象大小(P274)
jvm

二、各內存區域配置(P275)
工具

我的總結

一、獲取老年代存活對象大小性能

使用 jmap -histo:live pid 獲取內存快照，此時會發生Full GC(此方式會影響線上服務的使用，若是使用此方式，能夠將改此應用降級後再執行)，觀察老年代存活對象大小，關於jmap等其餘jdk工具更多使用方式能夠參考 JDK內置工具使用網站
開啓GC日誌打印，例配置jvm參數 -XX:+PrintGC 觀察屢次Full GC後老年代存活對象的大小取平均值爲準操作系統

二、設置jvm內存區域大小.net

約定：以 old_size 表示通過Full GC後老年代存活對象大小3d

整個堆大小設置爲 old_size 在的 3-4 倍
堆中新生代大小爲 old_size 的 1-1.5倍
堆中老年代大小爲 old_size 的 2-3倍，默認新生代與老年代的比例爲 1：2 ，不衝突
老年代(jdk8爲元數據MetaSpace)大小爲 old_size 的 1.2-1.5倍

三、配置實踐日誌

首先觀察一下一個已經運行了33天的vm的gc情況：
在33天內發生了1151次minor gc,每次12323/1151=10.7ms，天天35次左右 ; 6次full gc，每次(12.823-12.323)/6=83.3ms,6天才一次，收集器新生代爲默認的CMS,每次發生的緣由都是Eden區沒法分配內存，綜上，內存基本沒什麼壓力低，幾天一次的stw幾乎對應用無任何影響，咱們能夠適當的讓此jvm活躍起來，減小內存等資源的空閒，把cpu充分的利用起來，再來看一下內存使用的狀況:

在未強制執行Full gc前：

能夠得到總的堆內存大小爲:MaxHeapSize=946M,新生代與老年代最大分別爲9461/3=315M、9462/3=630M,此時老年代使用大小爲118M

在強制full gc後：

老年代存活對象大小爲：91M，那麼整個堆設置大小在 91 x 4=364M，永久代(元數據)在 91 x 1.5=136M

修改tomcat配置以下:

修改後堆內存分配，沒有意外

查詢gc狀況

發如今應用啓動階段會發生屢次minor gc與少許full GC，我想緣由也比較明顯，在應用啓動階段，須要建立不少對象，這些對象在新生代達到必定大小就會伴隨着minor gc的發生，full gc也如此...

四、更多
如何設置各區域內存，除了此推薦配置外，還須要根據應用特性和硬件環境等其餘因素來考慮，例如在32位計算機中，操做系統對進程內存大小是有限制的，設想一個進程限制爲2G,那麼對應用的堆內存又該如何配置呢?除了劃分堆內存，直接內存溢出也會發生OutOfMemoryError。在64位計算機中，單應用若是自己體積就比較大，老年代對象比較多，發生一次Full GC所花費的時間可能會達到幾秒甚至幾十秒，此時又有什麼比較好的解決方式呢?一些簡單可行的方法就是設置較大內存來使Full GC儘可能少的發生，在流量較少的階段強制Full GC或重啓等，在代碼層面咱們能夠儘可能少的建立大對象，使對象在新生代朝生夕死，減小老年代的壓力...

關於內存該如何設置?須要根據這些已有經驗與應用特性來綜合考慮...