2. 程式人生 > >容器中的JVM資源該如何被安全的限制？

容器中的JVM資源該如何被安全的限制？

阿新 • • 發佈：2019-01-02

容器中的JVM資源該如何被安全的限制？

前言

Java與Docker的結合，雖然更好的解決了application的封裝問題。但也存在著不相容，比如Java並不能自動的發現Docker設定的記憶體限制,CPU限制。

這將導致JVM不能穩定服務業務！容器會殺死你JVM程序，而健康檢查又將拉起你的JVM程序，進而導致你監控你的pod一天重啟次數甚至能達到幾百次。 

我們希望當Java程序執行在容器中時，java能夠自動識別到容器限制，獲取到正確的記憶體和CPU資訊，而不用每次都需要在kubernetes的yaml描述檔案中顯示的配置完容器，還需要配置JVM引數。

使用JVM MaxRAM引數或者解鎖實驗特性的JVM引數，升級JDK到10+，我們可以解決這個問題（也許吧~.~）。

首先Docker容器本質是是宿主機上的一個程序，它與宿主機共享一個/proc目錄，也就是說我們在容器內看到的/proc/meminfo，/proc/cpuinfo
與直接在宿主機上看到的一致，如下。

  • Host

    1
    2
    3
    4
    		 
    cat /proc/meminfo 
    MemTotal:       197869260 kB
    MemFree:         3698100 kB
    MemAvailable:   62230260 kB

  • 容器

    1
    2
    3
    4
     
    docker run -it --rm alpine cat /proc/meminfo
    MemTotal:       197869260 kB
    MemFree:         3677800 kB
    MemAvailable:   62210088 kB

那麼Java是如何獲取到Host的記憶體資訊的呢？沒錯就是通過/proc/meminfo來獲取到的。

預設情況下，JVM的Max Heap Size是系統記憶體的1/4，假如我們系統是8G，那麼JVM將的預設Heap≈2G。

Docker通過CGroups完成的是對記憶體的限制，而/proc目錄是已只讀形式掛載到容器中的，由於預設情況下Java
壓根就看不見CGroups的限制的記憶體大小，而預設使用/proc/meminfo

中的資訊作為記憶體資訊進行啟動，
這種不相容情況會導致，如果容器分配的記憶體小於JVM的記憶體，JVM程序會被理解殺死。

記憶體限制不相容

我們首先來看一組測試，這裡我們採用一臺記憶體為188G的物理機。

1
2
3
4
 

#free -g
              total        used        free      shared  buff/cache   available
Mem:            188         122           1           0          64          64

以下的測試中，我們將包含openjdk的hotspot虛擬機器，IBM的openj9虛擬機器。

以下測試中，我們把正確識別到限制的jdk，稱之為安全（即不會超出容器限制不會被kill），反之稱之為危險。

測試用例1(OPENJDK)

這一組測試我們使用最新的openjdk8-12，給容器限制記憶體為4G，看JDK預設引數下的最大堆為多少？看看我們預設引數下多少版本的JDK是安全的

  • 命令如下，如果你也想試試看，可以用一下命令。

    1
    2
    3
    4
    5
    		 
    docker run -m 4GB  --rm  openjdk:8-jre-slim java  -XshowSettings:vm  -version
    docker run -m 4GB --rm  openjdk:9-jre-slim java  -XshowSettings:vm  -version
    docker run -m 4GB --rm  openjdk:10-jre-slim java -XshowSettings:vm  -version
    docker run -m 4GB --rm  openjdk:11-jre-slim java -XshowSettings:vm  -version
    docker run -m 4GB --rm  openjdk:12 java -XshowSettings:vm  -version

  • OpenJDK8（並沒有識別容器限制，26.67G） 危險

1
2
3
4
5
6
7
8
9
10
 
[[email protected] ~]# docker run -m 4GB --rm  openjdk:8-jre-slim java  -XshowSettings:vm  -version

VM settings:
    Max. Heap Size (Estimated): 26.67G
 Ergonomics Machine Class: server
 Using VM: OpenJDK 64-Bit Server VM

openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
  • OpenJDK8 -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap （正確的識別容器限制，910.50M）安全
1
2
3
4
5
6
7
8
9
 
[[email protected] ~]# docker run -m 4GB --rm  openjdk:8-jre-slim java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XshowSettings:vm  -version
VM settings:
    Max. Heap Size (Estimated): 910.50M
    Ergonomics Machine Class: server
 Using VM: OpenJDK 64-Bit Server VM

openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
  • OpenJDK 9（並沒有識別容器限制，26.67G）危險
1
2
3
4
5
6
7
8
 
[[email protected] ~]# docker run -m 4GB --rm  openjdk:9-jre-slim java  -XshowSettings:vm  -version
VM settings:
    Max. Heap Size (Estimated): 29.97G
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode)
  • OpenJDK 9 -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap （正確的識別容器限制，1G）安全
1
2
3
4
5
6
7
8
 
[[email protected] ~]# docker run -m 4GB --rm  openjdk:9-jre-slim java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XshowSettings:vm  -version
VM settings:
    Max. Heap Size (Estimated): 1.00G
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode)
  • OpenJDK 10（正確的識別容器限制，1G）安全
1
2
3
4
5
6
7
8
 
[[email protected] ~]# docker run -m 32GB --rm  openjdk:10-jre-slim java -XshowSettings:vm -XX:MaxRAMFraction=1  -version
VM settings:
    Max. Heap Size (Estimated): 1.00G
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Debian-2)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Debian-2, mixed mode)
  • OpenJDK 11（正確的識別容器限制，1G）安全
1
2
3
4
5
6
7
8
 
[[email protected] ~]# docker run -m 4GB --rm  openjdk:11-jre-slim java -XshowSettings:vm  -version
VM settings:
    Max. Heap Size (Estimated): 1.00G
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment (build 11.0.1+13-Debian-3)
OpenJDK 64-Bit Server VM (build 11.0.1+13-Debian-3, mixed mode, sharing)
  • OpenJDK 12（正確的識別容器限制，1G）安全
1
2
3
4
5
6
7
8
 
[[email protected] ~]# docker run -m 4GB --rm  openjdk:12 java -XshowSettings:vm  -version
VM settings:
    Max. Heap Size (Estimated): 1.00G
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment (build 12-ea+23)
OpenJDK 64-Bit Server VM (build 12-ea+23, mixed mode, sharing)

測試用例2(IBMOPENJ9)

1
2
3
4
 
docker run -m 4GB --rm  adoptopenjdk/openjdk8-openj9:alpine-slim  java -XshowSettings:vm  -version
docker run -m 4GB --rm  adoptopenjdk/openjdk9-openj9:alpine-slim  java -XshowSettings:vm  -version
docker run -m 4GB --rm  adoptopenjdk/openjdk10-openj9:alpine-slim  java -XshowSettings:vm  -version
docker run -m 4GB --rm  adoptopenjdk/openjdk11-openj9:alpine-slim  java -XshowSettings:vm  -version

  • openjdk8-openj9 （正確的識別容器限制，3G）安全

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    		 
    [[email protected] ~]# docker run -m 4GB --rm  adoptopenjdk/openjdk8-openj9:alpine-slim  java -XshowSettings:vm  -version
    VM settings:
        Max. Heap Size (Estimated): 3.00G
        Ergonomics Machine Class: server
     Using VM: Eclipse OpenJ9 VM

    openjdk version "1.8.0_192"
    OpenJDK Runtime Environment (build 1.8.0_192-b12_openj9)
    Eclipse OpenJ9 VM (build openj9-0.11.0, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20181107_95 (JIT enabled, AOT enabled)
    OpenJ9 - 090ff9dcd
    OMR - ea548a66
    JCL - b5a3affe73 based on jdk8u192-b12)

  • openjdk9-openj9 （正確的識別容器限制，3G）安全

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    		 
    [[email protected] ~]# docker run -m 4GB --rm  adoptopenjdk/openjdk9-openj9:alpine-slim  java -XshowSettings:vm  -version
    VM settings:
        Max. Heap Size (Estimated): 3.00G
        Using VM: Eclipse OpenJ9 VM

    openjdk version "9.0.4-adoptopenjdk"
    OpenJDK Runtime Environment (build 9.0.4-adoptopenjdk+12)
    Eclipse OpenJ9 VM (build openj9-0.9.0, JRE 9 Linux amd64-64-Bit Compressed References 20180814_248 (JIT enabled, AOT enabled)
    OpenJ9 - 24e53631
    OMR - fad6bf6e
    JCL - feec4d2ae based on jdk-9.0.4+12)

  • openjdk10-openj9 （正確的識別容器限制，3G）安全

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    		 
    [[email protected] ~]# docker run -m 4GB --rm  adoptopenjdk/openjdk10-openj9:alpine-slim  java -XshowSettings:vm  -version
    VM settings:
        Max. Heap Size (Estimated): 3.00G
        Using VM: Eclipse OpenJ9 VM

    openjdk version "10.0.2-adoptopenjdk" 2018-07-17
    OpenJDK Runtime Environment (build 10.0.2-adoptopenjdk+13)
    Eclipse OpenJ9 VM (build openj9-0.9.0, JRE 10 Linux amd64-64-Bit Compressed References 20180813_102 (JIT enabled, AOT enabled)
    OpenJ9 - 24e53631
    OMR - fad6bf6e
    JCL - 7db90eda56 based on jdk-10.0.2+13)

  • openjdk11-openj9（正確的識別容器限制，3G）安全

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    		 
    [[email protected] ~]# docker run -m 4GB --rm  adoptopenjdk/openjdk11-openj9:alpine-slim  java -XshowSettings:vm  -version
    VM settings:
        Max. Heap Size (Estimated): 3.00G
        Using VM: Eclipse OpenJ9 VM

    openjdk version "11.0.1" 2018-10-16
    OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.1+13)
    Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.11.0, JRE 11 Linux amd64-64-Bit Compressed References 20181020_70 (JIT enabled, AOT enabled)
    OpenJ9 - 090ff9dc
    OMR - ea548a66
    JCL - f62696f378 based on jdk-11.0.1+13)

分析

分析之前我們先了解這麼一個情況：

1
 
JavaMemory (MaxRAM) = 元資料+執行緒+程式碼快取+OffHeap+Heap...

 

一般我們都只配置Heap即使用-Xmx來指定JVM可使用的最大堆。而JVM預設會使用它獲取到的最大記憶體的1/4作為堆的原因也是如此。

安全性（即不會超過容器限制被容器kill）

OpenJdk

OpenJdk8-12,都能保證這個安全性的特點（8和9需要特殊引數，-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap）。

OpenJ9

2.IbmOpenJ9所有的版本都能識別到容器限制。

資源利用率

OpenJdk

自動識別到容器限制後，OpenJdk把最大堆設定為了大概容器記憶體的1/4，對記憶體的浪費不可謂不大。

當然可以配合另一個JVM引數來配置最大堆。-XX:MaxRAMFraction=int。下面是我整理的一個常見記憶體設定的表格，
從中我們可以看到似乎JVM預設的最大堆的取值為MaxRAMFraction=4，隨著記憶體的增加，堆的閒置空間越來越大，在16G容器記憶體時，java堆只有不到4G。

MaxRAMFraction取值 堆佔比 容器記憶體=1G 容器記憶體=2G 容器記憶體=4G 容器記憶體=8G 容器記憶體=16G
1 ≈90% 910.50M 1.78G 3.56G 7.11G 14.22G
2 ≈50% 455.50M 910.50M 1.78G 3.56G 7.11G
3 ≈33% 304.00M 608.00M 1.19G 2.37G 4.74G
4 ≈25% 228.00M 455.50M 910.50M 1.78G 3.56G

OpenJ9

關於OpenJ9的的詳細介紹你可以從這裡瞭解更多。
對於記憶體利用率OpenJ9的策略是優於OpenJdk的。以下是OpenJ9的策略表格

容器記憶體<size> 最大Java堆大小
小於1 GB 50％<size>
1 GB - 2 GB <size> - 512 MB
大於2 GB 大於2 GB

結論

  • 注意：這裡我們說的是容器記憶體限制，和物理機記憶體不同，

自動檔

  • 如果你想要的是，不顯示的指定-Xmx，讓Java程序自動的發現容器限制。

1.如果你想要的是jvm程序在容器中安全穩定的執行，不被容器kiil，並且你的JDK版本小於10（大於等於JDK10的版本不需要設定，參考前面的測試）
你需要額外設定JVM引數-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap，即可保證你的Java程序不會因為記憶體問題被容器Kill。
當然這個方式使用起來簡單，可靠，缺點也很明顯，資源利用率過低（參考前面的表格MaxRAMFraction=4）。

2.如果想在基礎上我還想提高一些記憶體資源利用率，並且容器記憶體為1 GB - 4 GB，我建議你設定-XX:MaxRAMFraction=2，在大於8G的可以嘗試設定-XX:MaxRAMFraction=1（參考上表格）。

手動擋

  • 如果你想要的是手動擋的體驗，更加進一步的利用記憶體資源，那麼你可能需要回到手動配置時代-Xmx。
  • 手動擋部分，請可以完全忽略上面我的BB。
    1.上面的我們說到了自動擋的配置，用起來很簡單很舒服，自動發現容器限制，無需擔心和思考去配置-Xmx。
    2.比如你有記憶體1G那麼我建議你的-Xmx750M,2G建議配置-Xmx1700M,4G建議配置-Xmx3500-3700M,8G建議設定-Xmx7500-7600M,
    總之就是至少保留300M以上的記憶體留給JVM的其他記憶體。如果堆特別大，可以預留到1G甚至2G。
    3.手動擋用起來就沒有那麼舒服了，當然資源利用率相對而言就更高了

相關推薦

容器中的JVM資源該如何被安全的限制？

容器中的JVM資源該如何被安全的限制？ 前言 Java與Docker的結合，雖然更好的解決了application的封裝問題。但也存在著不相容，比如Java並不能自動的發現Docker設定的記憶體限制,CPU限制。 這將導致JVM不能穩定服務業務！容器會殺死你JVM程序，而健康檢查又將拉起你的

EJB和Web容器中的資源或元件是如何查詢的?

JavaEE中資源或元件是如何通過JNDI查詢的一直都沒完全弄清楚，這段時間花時間總算把它弄清楚了，總結如下： (a).JavaEE1.5以前: ServletA.java: InitialContext ic=new InitialContext(); DataSour

Docker容器中MySQL最大連接數被限制為214的解決方案

wan tin lease 有一點 ria preview eating phoenix 感謝 原文:Docker容器中MySQL最大連接數被限制為214的解決方案

win 10 無法刪除系統文件的解決方法(提示：無法枚舉容器中的對象 訪問被拒絕)

gin 技術 分享 解決 sys 被拒絕 權限 結束 除了 一、右擊文件 選擇“屬性”-“安全”-“高級”，如下圖 　　 二、查看哪個用戶的權限是：“完全控制”，我這裏是“SYSTEM”用戶。 三、選擇頂部的 “更改-“高級”-“立即查找”，然後選擇管理員賬戶“SYSTE

JIRA應用的記憶體引數設定不當+容器沒有對資源進行限制導致服務掛掉的例子

背景: 應用的部署結構是這樣的:使用rancher管理的Docker叢集,有三臺物理主機,二十多個Docker容器, 提供的功能是問題跟蹤(JIRA),文件管理(Confluence),程式碼託管(svn,gitlab),持續整合(jenkins,gitlab-ci + Docker),程式碼質量管理(Son

web容器向jar中尋找資源

示例程式碼下載地址 https://files.cnblogs.com/files/Mike_Chang/web%E5%AE%B9%E5%99%A8%E5%90%91jar%E4%B8%AD%E5%AF%BB%E6%89%BE%E8%B5%84%E6%BA%90.rar 具體步驟  1、在

JavaWeb問題集錦: CentOS 7中MySQL連線數被限制為214個的解決方法

這篇文章主要給大家介紹了關於CentOS 7中MySQL連線數被限制為214個的解決方法，文中通過示例程式碼介紹的非常詳細，對大傢俱有一定的參考學習價值，需要的朋友們下面跟著小編來一起看看吧。 發現問題 最近在專案中遇到一個問題，由於連線數過多，提示 “Too many con

Spring原始碼解析-7、spring容器中的Bean是否執行緒安全？

Spring容器中的Bean是否執行緒安全，容器本身並沒有提供Bean的執行緒安全策略，因此可以說spring容器中的Bean本身不具備執行緒安全的特性，但是具體還是要結合具體scope的Bean去研究。 spring 的 bean 有哪些scope[作用域] 1、singleton

Java中哪些是執行緒安全的容器？

同步容器類：使用了synchronized 1.Vector 2.HashTable 併發容器： 3.ConcurrentHashMap:分段 4.CopyOnWriteArrayList：寫時複製 5.CopyOnWriteArraySet：寫時複製 Queue: 6.Concur

安裝軟體過程中，資源被佔用問題

安裝軟體過程中總會出現如下問題： E: 無法獲得鎖 /var/lib/dpkg/lock - open (11: 資源暫時不可用) E: 無法鎖定管理目錄(/var/lib/dpkg/)，是否有其他程序正佔用它？ 解決方法： 1）終端輸入 ps  aux ，列出程序。找

SpringMVC中設定靜態資源不被攔截的問題

        這兩天使用SpringMVC來做登入，註冊的小demo，其中用到了springmvc攔截器對登入操作進行攔截處理，並對url進行驗證。 驗證通過則可以進行handler的處理，如果驗證不通過直接跳回或者重定向到指定的頁面。         但是在做這個操作的

關於限制子窗體在父容器中移動邊界的總結(很簡單的東西,寫給新人)

有時候,我們直接用MDI父窗體+MDI窗體可以方便的構建多文件應用,但在有些時候,我們不選擇使用MDI窗體形式, 可能是出於某些限制,比如,你需要在父窗體中使用控制元件,但老是把新建的子窗體給遮住,你選擇使用panel物件來裝一個視窗,可是因為窗體如果 是有邊框的,就會讓輸

Kubernetes安全三步談：如何監控與控制Kubernetes中的資源消耗問題

或許很多人可能認為資源消耗並非安全問題，但實際上不合理的資源消耗會讓黑客有可乘之機，來攻擊K8s的元件。本文將介紹如何處理資源消耗

css中那些屬性可以被繼承

mil 屬性 ria ext direct tran ade weight -s 主要的有： 字體相關：line-height, font-family, font-size, font-style, font-variant, font-weight, font 文本相關

解決node使用中8080端口被占用

查看 alt 結束進程 nbsp 重新 分享 img logs 相同 1、首先按快捷鍵windows+R，在運行框裏輸入cmd，如圖所示，進入黑色界面後，輸入netstat -ano，查看端口。 2、找到8080端口，查看正在運行程序的pid，如圖所示。 3、回到桌面，

如何在 CentOS 7 中安裝、配置和安全加固 FTP 服務

cte success fire lease 註意 tps tran sub linux 步驟 1：安裝 FTP 服務器 1、 安裝 vsftpd 服務器很直接，只要在終端運行下面的命令。 # yum install vsftpd 2、 安裝完成後，服務先是被禁用的，因

Java中獲取資源文件的方法總結

tco doget 技術 resource images 磁盤 response linux exception 這裏總結3中方法獲取資源文件的 ServletContext Class ClassLoader 文件的位置 1. ServletC

IDEA 在某個工程下一個module如何使用另一個module中的資源文件（.xml .prop等）

blog mave 一個 pid 技術 mage module 如何使用 依賴關系 問題如題，經google，解決方案有四種，選擇了比較直觀有效的一種羅列如下： 因為項目采用maven管理，所以我們可以在module2下的pom.xml制定<resource

讓一個元素在容器中垂直居中的幾個方法

body 垂直居中 -s ntb offset set log off htm 方法一，使用js讓元素水平垂直居中 <!DOCTYPE html> <html> <head> <meta charset

在Docker容器中運行.Net Core web Api項目

c99 images sof 以及 store .com 查看 .html microsoft 安裝Docker環境 參考本人這篇《CentOS 7 下Docker的安裝》文章進行安裝以及環境配置，這裏不做贅述。 通過.NetCore開發WebApi項目 1. 創建.Net