談JVM xmx, xms等記憶體相關引數合理性設定
作者:京東零售 劉樂
吞吐量和停頓時長,這兩個優化目標是有衝突的。那麼有沒有可能提高吞吐量而不影響停頓時長,甚至縮短停頓時長呢?答案是有可能的,提高記憶體佔用(Memory Footprint)就有可能同時優化這兩個標的,這篇文章就來聊聊記憶體相關內容。
記憶體佔用一般指應用執行需要的所有記憶體,包括堆內記憶體(On-heap Memory)和堆外記憶體(Off-heap Memory)
1. 堆內記憶體
堆內記憶體是分配給JVM的部分記憶體,用來存放所有Java Class物件例項和陣列,JVM GC操作的就是這部分內容。我們先來回顧一下堆內記憶體的模型:
圖1. 堆內記憶體
堆內記憶體包括年輕代(淺綠色),老年代(淺藍色),在JDK7或者更老的版本,圖中右邊還有個永久代(永久代在邏輯上位於JVM的堆區,但又被稱為非堆記憶體,在JDK8中被元空間取代)。JVM有動態調整記憶體策略,通過-Xms,-Xmx指定堆內記憶體動態調整的上下限。 在JVM初始化時實際只分配部分記憶體,可通過-XX:InitialHeapSize指定初始堆記憶體大小,未被分配的空間為圖中virtual部分。年輕代和老年代在每次GC的時候都有可能調整大小,以保證存活物件佔用百分比在特定閾值範圍內,直到達到Xms指定的下限或Xms指定的上限。(閾值範圍通過-XX:MinHeapFreeRatio,XX:MaxHeapFreeRatio指定,預設值分別為40, 70)。
GC調優中還有個的重要引數是老年代和年輕代的比例,通過-XX:NewRatio設定,與此相關的還有-XX:MaxNewSize和-XX:NewSize,分別設定年輕代大小的上下限,-Xmn則直接指定年輕代的大小。
1.1 引數預設值
◦-Xmx: Xmx的預設值比較複雜,官方文件上有時候寫的是1GB,但實際值跟JRE版本、JVM 模式(client, server)和系統(平臺型別,32位,64位)等都有關。經過查閱原始碼和實驗,確定在生產環境下(server模式,64位Centos,JRE 8),Xmx的預設值可以採用以下規則計算:
▪容器記憶體小於等於2G:預設值為容器記憶體的1/2,最小16MB, 最大512MB。
▪容器記憶體大於2G:預設值為容器記憶體的1/4, 最大可到達32G。
◦-Xms: 預設值為容器記憶體的1/64, 最小8MB,如果明確指定了Xmx並且小於容器記憶體1/64, Xms預設值為Xmx指定的值。
◦-NewRatio: 預設2,即年輕代和年老代的比例為1:2, 年輕代大小為堆內記憶體的1/3。
NOTE:在JRE版本1.8.0_131之前,JVM無法感知Docker的資源限制,Xmx, Xms未明確指定時,會使用宿主機的記憶體計算預設值。
1.2 最佳實踐
由於每次Eden區滿就會觸發YGC,而每次YGC的時候,晉升到老年代的物件大小超過老年代剩餘空間的時候,就會觸發FGC。所以基本來說,GC頻率和堆內記憶體大小是成反比的,也就是說堆內記憶體越大,吞吐量越大。
如果Xmx設定過小,不僅浪費了容器資源,在大流量下會頻繁GC,導致一系列問題,包括吞吐量降低,響應變長,CPU升高,
java.lang.OutOfMemoryError異常等。當然Xmx也不建議設定過大,否則會導致程序hang住或者使用容器Swap。所以合理設定Xmx非常重要,特別是對於1.8.0_131之前的版本,一定要明確指定Xmx。推薦設定為容器記憶體的50%,不能超過容器記憶體的80%。
JVM的動態記憶體策略不太適合服務使用,因為每次GC需要計算Heap是否需要伸縮,記憶體抖動需要向系統申請或釋放記憶體,特別是在服務重啟的預熱階段,記憶體抖動會比較頻繁。另外,容器中如果有其他程序還在消費記憶體,JVM記憶體抖動時可能申請記憶體失敗,導致OOM。因此建議服務模式下,將Xms設定Xmx一樣的值。
NewRatio建議在2~3之間,最優選擇取決於物件的生命週期分佈。一般先確定老年代的空間(足夠放下所有live data,並適當增加10%~20%),其餘是年輕代,年輕代大小一定要小於老年代。
另外,以上建議都是基於一個容器部署一個JVM例項的使用情況。有個別需求,需要在一個容器內啟用多個JVM,或者包含其他語言的,研發需要按業務需求在推薦值範圍內分配JVM的Xmx。
2. 堆外記憶體
和堆內記憶體對應的就是堆外記憶體。堆外記憶體包括很多部分,比如Code Cache, Memory Pool,Stack Memory,Direct Byte Buffers, Metaspace等等,其中我們需要重點關注的是Direct Byte Buffers和Metaspace。
2.1 Direct Byte Buffers
Direct Byte Buffers是系統原生記憶體,不位於JVM裡,狹義上的堆外記憶體就是指的Direct Byte Buffers。為什麼要使用系統原生記憶體呢? 為了更高效的進行Socket I/O或檔案讀寫等核心態資源操作,會使用JNI(Java原生介面),此時操作的記憶體需要是連續和確定的。而Heap中的記憶體不能保證連續,且GC也可能導致物件隨時移動。因此涉及Output操作時,不直接使用Heap上的資料,需要先從Heap上拷貝到原生記憶體,Input操作則相反。因此為了避免多餘的拷貝,提高I/O效率,不少第三方包和框架使用Direct Byte Buffers,比Netty。
Direct Byte Buffers雖然有上述優點,但使用起來也有一定風險。常見的Direct Byte Buffers使用方法是用java.nio.DirectByteBuffer的unsafe.allocateMemory方法來建立,DirectByteBuffer物件只儲存了系統分配的原生記憶體的大小和啟始位置,這些原生記憶體的釋放需要等到DirectByteBuffer物件被回收。有些特殊的情況下(比如JVM一直沒有FGC,設定-XX:+DisableExplicitGC禁用了System.gc),這部分物件會持續增加,直到堆外記憶體達到-XX:MaxDirectMemorySize指定的大小或者耗盡所有的系統記憶體。
MaxDirectMemorySize不明確指定的時候,預設值為0,在程式碼中實際為Runtime.getRuntime().maxMemory(),略小於-Xmx指定的值(堆內記憶體的最大值減去一個Survivor區大小)。此預設值有點過大,MaxDirectMemorySize未設定或設定過大,有可能發生堆外記憶體洩露,導致程序被系統Kill。
由於存在一定風險,建議在啟動引數裡明確指定-XX:MaxDirectMemorySize的值,並滿足下面規則:
◦Xmx * 110% + MaxDirectMemorySize + 系統預留記憶體 <= 容器記憶體
◦Xmx * 110% 中額外的10%是留給其他堆外記憶體的,是個保守估計,個別業務執行時執行緒較多,需自行判斷,上式中左側還需加上Xss * 執行緒數
◦系統預留記憶體512M到1G,視容器規格而定
◦I/O較多的業務適當提高MaxDirectMemorySize比例
2.2 Metaspace
Metaspace(元空間)是JDK8關於方法區新的實現,取代之前的永久代,用來儲存類、方法、資料結構等執行時資訊和元資訊的。很多研發在老版本時可能遇到過
java.lang.OutOfMemoryError: PermGen Space,這說明永久代的空間不夠用了,可以通過-XX:PermSize,-XX:MaxPermSize來指定永久代的初始大小和最大大小。Metaspace取代永久代,位置由JVM記憶體變成系統原生記憶體,也取消預設的最大空間限制。與此有關的引數主要有下面兩個:
◦-XX:MaxMetaspaceSize指定元空間的最大空間,預設為容器剩餘的所有空間
◦-XX:MetaspaceSize指定元空間首次擴充的大小,預設為20.8M
由於MaxMetaspaceSize未指定時,預設無上限,所以需要特別關注記憶體洩露的問題,如果程式動態的建立了很多類,或出現過
java.lang.OutOfMemoryError:Metaspace,建議明確指定-XX:MaxMetaspaceSize。另外Metaspace實際分配的大小是隨著需要逐步擴大的,每次擴大需要一次FGC,-XX:MetaspaceSize預設的值比較小,需要頻繁GC擴充到需要的大小。通過下面的日誌可以看到Metaspace引起的FGC:
[Full GC (Metadata GC Threshold) ...]
為減少預熱影響,可以將-XX:MetaspaceSize,-XX:MaxMetaspaceSize指定成相同的值。另外不少應用由JDK7升級到了JDK8,但是啟動引數中仍有-XX:PermSize,-XX:MaxPermSize,這些引數是不生效的,建議修改成-XX:MetaspaceSize,-XX:MaxMetaspaceSize。
3. 應用健康度檢查規則
泰山應用健康度現在已支援掃描JVM相關風險,在應用TAB的JVM配置檢測項下。主要包括以下檢測:
檢測指標 | 風險等級 | 巡檢規則 |
---|---|---|
JVM版本 | 中危 | 版本不低於1.8.0_191 |
JVM GC方法 | 中危 | 所有分組GC方法一致 |
Xmx | 高危 | 明確指定,並且在容器記憶體的50%~80%範圍內 |
Xms | 中危 | 明確指定,並且等於Xmx指定的值 |
堆外記憶體 | 中危 | 明確指定,並且 堆內*1.1+堆外+系統預留<=容器記憶體 |
ParallelGCThreads | 高危 | ParallelGCThreads在容器CPU核數的50%~100%範圍內 |
ConcGCThreads | 低危 | ConcGCThreads在ParallelGCThreads的20%~50%範圍內(限CMS,G1) |
CICompilerCount | 低危 | 指定CICompilerCount在推薦值50%~150%內(限1.8<JRE<1.8.0_131) |
上一篇文章已經說了ParallelGCThreads,這裡再補充一下新支援的兩個檢測,ConcGCThreads,CICompilerCount。
ConcGCThreads一般稱為併發標記執行緒數,為了減少GC的STW的時間,CMS和G1都有併發標記的過程,此時業務執行緒仍在工作,只是併發標記是CPU密集型任務,業務的吞吐量會下降,RT會變長。ConcGCThreads的預設值不同GC策略略有不同,CMS下是(ParallelGCThreads + 3) / 4 向下取整,G1下是ParallelGCThreads / 4 四捨五入。一般來說採用預設值就可以了,但是還是由於在JRE版本1.8.0_131之前,JVM無法感知Docker的資源限制的問題,ConcGCThreads的預設值會比較大(20左右),對業務會有影響。
CICompilerCount是JIT進行熱點編譯的執行緒數,和併發標記執行緒數一樣,熱點編譯也是CPU密集型任務,預設值為2。在CICompilerCountPerCPU開啟的時候(JDK7預設關閉,JDK8預設開啟),手動指定CICompilerCount是不會生效的,JVM會使用系統CPU核數進行計算。所以當使用JRE8並且版本小於1.8.0_131,採用預設引數時,CICompilerCount會在20左右,對業務效能影響較大,特別是啟動階段。建議升級Java版本,特殊情況要使用老版本Java 8,請加上-XX:CICompilerCount=[n], 同時不能指定-XX:+CICompilerCountPerCPU,下表給出了生產環境下常見規格的推薦值。
容器CPU核數 | 1 | 2 | 4 | 8 | 16 |
---|---|---|---|---|---|
CICompilerCount手動指定推薦值 | 2 | 2 | 3 | 3 | 8 |
4. 修改建議
1) 再次建議升級JRE版本到1.8.0_191及以上; 2) 建議在Shell指令碼中,Export JAVA_OPTS環境變數, 至少包含以下幾項(方括號中的值根據文中推薦選取):
-server -Xms[8192m] -Xmx[8192m] -XX:MaxDirectMemorySize=[4096m]
如果特殊原因要使用1.8.0_131以下版本, 則同時需要加上以下引數(方括號中的值根據文中推薦選取):
-XX:ParallelGCThreads=[8] -XX:ConcGCThreads=[2] -XX:CICompilerCount=[2]
下面的項建議測試後使用,需自行確定具體大小(特別是使用JRE8但仍配置-XX:PermSize,-XX:MaxPermSize的應用):
-XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m
環境變數設定如下例子:
export JAVA_OPTS="-Djava.library.path=/usr/local/lib -server -Xms4096m -Xmx4096m -XX:MaxMetaspaceSize=512m -XX:MetaspaceSize=512m -XX:MaxDirectMemorySize=2048m -XX:ParallelGCThreads=8 -XX:ConcGCThreads=2 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/export/Logs -XX:+UseG1GC [other_options...] -jar jarfile [args...]"
另外,如果應用未接入UMP或PFinder, JAVA_OPTS中儘量不要用Shell函式或者變數,否則健康度有可能會提示解析失敗。
NOTE: Java options 的使用應該按照下面的順序:
◦執行類: java [-options] class [args...]
◦執行包:java [-options] -jar jarfile [args...] 或 java -jar [-options] jarfile [args...]
即options要放到執行物件之前,部分應用使用了以下順序:
java -jar jarfile [-options] [args...] 或者 java -jar jarfile [args...] [-options]
這些Java options都不會生效。
- 應用健康度隱患刨析解決系列之資料庫時區設定
- 對於Vue3和Ts的心得和思考
- 一文詳解擴散模型:DDPM
- zookeeper的Leader選舉原始碼解析
- 一文帶你搞懂如何優化慢SQL
- 京東金融Android瘦身探索與實踐
- 微前端框架single-spa子應用載入解析
- cookie時效無限延長方案
- 聊聊前端效能指標那些事兒
- Spring竟然可以建立“重複”名稱的bean?—一次專案中存在多個bean名稱重複問題的排查
- 京東金融Android瘦身探索與實踐
- Spring原始碼核心剖析
- 深入淺出RPC服務 | 不同層的網路協議
- 安全測試之探索windows遊戲掃雷
- 關於資料庫分庫分表的一點想法
- 對於Vue3和Ts的心得和思考
- Bitmap、RoaringBitmap原理分析
- 京東小程式CI工具實踐
- 測試用例設計指南
- 當你對 redis 說你中意的女孩是 Mia