摘要:本系列文章會記錄阿里云容器服務團隊在支持客戶中的一些心得體會和最佳實踐。阿里云服務全球首批通過一致性認證,簡化了集群生命周期管理,內置了與阿里云產品集成,也將進一步簡化的開發者體驗,幫助用戶關注云端應用價值創新。
隨著容器技術的成熟,越來越多的企業客戶在企業中選擇Docker和Kubernetes作為應用平臺的基礎。然而在實踐過程中,還會遇到很多具體問題。本系列文章會記錄阿里云容器服務團隊在支持客戶中的一些心得體會和最佳實踐。我們也歡迎您通過郵件和釘釘群和我們聯系,分享您的思路和遇到的問題。
問題有些同學反映:自己設置了容器的資源限制,但是Java應用容器在運行中還是會莫名奇妙地被OOM Killer干掉。
這背后一個非常常見的原因是:沒有正確設置容器的資源限制以及對應的JVM的堆空間大小。
我們拿一個tomcat應用為例,其實例代碼和Kubernetes部署文件可以從Github中獲得。
git clone https://github.com/denverdino/system-info cd system-info`
下面是一個Kubernetes的Pod的定義描述:
Pod中的app是一個初始化容器,負責把一個JSP應用拷貝到 tomcat 容器的 “webapps”目錄下。注:
鏡像中JSP應用index.jsp用于顯示JVM和系統資源信息。
tomcat 容器會保持運行,而且我們限制了容器最大的內存用量為256MB內存。
apiVersion: v1 kind: Pod metadata: name: test spec: initContainers: - image: registry.cn-hangzhou.aliyuncs.com/denverdino/system-info name: app imagePullPolicy: IfNotPresent command: - "cp" - "-r" - "/system-info" - "/app" volumeMounts: - mountPath: /app name: app-volume containers: - image: tomcat:9-jre8 name: tomcat imagePullPolicy: IfNotPresent volumeMounts: - mountPath: /usr/local/tomcat/webapps name: app-volume ports: - containerPort: 8080 resources: requests: memory: "256Mi" cpu: "500m" limits: memory: "256Mi" cpu: "500m" volumes: - name: app-volume emptyDir: {}
我們執行如下命令來部署、測試應用
$ kubectl create -f test.yaml pod "test" created $ kubectl get pods test NAME READY STATUS RESTARTS AGE test 1/1 Running 0 28s $ kubectl exec test curl http://localhost:8080/system-info/ ...
我們可以看到HTML格式的系統CPU/Memory等信息,我們也可以用 html2text 命令將其轉化成為文本格式。
注意:本文是在一個 2C 4G的節點上進行的測試,在不同環境中測試輸出的結果會有所不同
$ kubectl exec test curl http://localhost:8080/system-info/ | html2text Java version Oracle Corporation 1.8.0_162 Operating system Linux 4.9.64 Server Apache Tomcat/9.0.6 Memory Used 29 of 57 MB, Max 878 MB Physica Memory 3951 MB CPU Cores 2 **** Memory MXBean **** Heap Memory Usage init = 65011712(63488K) used = 19873704(19407K) committed = 65536000(64000K) max = 921174016(899584K) Non-Heap Memory Usage init = 2555904(2496K) used = 32944912(32172K) committed = 33882112(33088K) max = -1(-1K)
我們可以發現,容器中看到的系統內存是 3951MB,而JVM Heap Size最大是 878MB。納尼?!我們不是設置容器資源的容量為256MB了嗎?如果這樣,當應用內存的用量超出了256MB,JVM還沒對其進行GC,而JVM進程就會被系統直接OOM干掉了。
問題的根源在于:
對于JVM而言,如果沒有設置Heap Size,就會按照宿主機環境的內存大小缺省設置自己的最大堆大小。
Docker容器利用CGroup對進程使用的資源進行限制,而在容器中的JVM依然會利用宿主機環境的內存大小和CPU核數進行缺省設置,這導致了JVM
Heap的錯誤計算。
類似,JVM缺省的GC、JIT編譯線程數量取決于宿主機CPU核數。如果我們在一個節點上運行多個Java應用,即使我們設置了CPU的限制,應用之間依然有可能因為GC線程搶占切換,導致應用性能收到影響。
了解了問題的根源,我們就可以非常簡單地解決問題了
解決思路開啟CGroup資源感知
Java社區也關注到這個問題,并在JavaSE8u131+和JDK9 支持了對容器資源限制的自動感知能力 https://blogs.oracle.com/java...
其用法就是添加如下參數
java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap …
我們在上文示例的tomcat容器添加環境變量 “JAVA_OPTS”參數
apiVersion: v1 kind: Pod metadata: name: cgrouptest spec: initContainers: - image: registry.cn-hangzhou.aliyuncs.com/denverdino/system-info name: app imagePullPolicy: IfNotPresent command: - "cp" - "-r" - "/system-info" - "/app" volumeMounts: - mountPath: /app name: app-volume containers: - image: tomcat:9-jre8 name: tomcat imagePullPolicy: IfNotPresent env: - name: JAVA_OPTS value: "-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap" volumeMounts: - mountPath: /usr/local/tomcat/webapps name: app-volume ports: - containerPort: 8080 resources: requests: memory: "256Mi" cpu: "500m" limits: memory: "256Mi" cpu: "500m" volumes: - name: app-volume emptyDir: {}
我們部署一個新的Pod,并重復相應的測試
$ kubectl create -f cgroup_test.yaml pod "cgrouptest" created $ kubectl exec cgrouptest curl http://localhost:8080/system-info/ | html2txt Java version Oracle Corporation 1.8.0_162 Operating system Linux 4.9.64 Server Apache Tomcat/9.0.6 Memory Used 23 of 44 MB, Max 112 MB Physica Memory 3951 MB CPU Cores 2 **** Memory MXBean **** Heap Memory Usage init = 8388608(8192K) used = 25280928(24688K) committed = 46661632(45568K) max = 117440512(114688K) Non-Heap Memory Usage init = 2555904(2496K) used = 31970840(31221K) committed = 32768000(32000K) max = -1(-1K)
我們看到JVM最大的Heap大小變成了112MB,這很不錯,這樣就能保證我們的應用不會輕易被OOM了。隨后問題又來了,為什么我們設置了容器最大內存限制是256MB,而JVM只給Heap設置了112MB的最大值呢?
這就涉及到JVM的內存管理的細節了,JVM中的內存消耗包含Heap和Non-Heap兩類;類似Class的元信息,JIT編譯過的代碼,線程堆棧(thread stack),GC需要的內存空間等都屬于Non-Heap內存,所以JVM還會根據CGroup的資源限制預留出部分內存給Non Heap,來保障系統的穩定。(在上面的示例中我們可以看到,tomcat啟動后Non Heap占用了近32MB的內存)
在最新的JDK 10中,又對JVM在容器中運行做了進一步的優化和增強。
容器內部感知CGroup資源限制
如果無法利用JDK 8/9的新特性,比如還在使用JDK6的老應用,我們還可以在容器內部利用腳本來獲取容器的CGroup資源限制,并通過設置JVM的Heap大小。
Docker1.7開始將容器cgroup信息掛載到容器中,所以應用可以從 /sys/fs/cgroup/memory/memory.limit_in_bytes 等文件獲取內存、 CPU等設置,在容器的應用啟動命令中根據Cgroup配置正確的資源設置 -Xmx, -XX:ParallelGCThreads等參數
在 https://yq.aliyun.com/article... 一文中已經有相應的示例和代碼,本文不再贅述
總結本文分析了Java應用在容器使用中一個常見Heap設置的問題。容器與虛擬機不同,其資源限制通過CGroup來實現。而容器內部進程如果不感知CGroup的限制,就進行內存、CPU分配可能導致資源沖突和問題。
我們可以非常簡單地利用JVM的新特性和自定義腳本來正確設置資源限制。這個可以解決絕大多數資源限制的問題。
關于容器應用中資源限制還有一類問題是,一些比較老的監控工具或者free/top等系統命令,在容器中運行時依然會獲取到宿主機的CPU和內存,這導致了一些監控工具在容器中運行時無法正常計算資源消耗。社區中常見的做法是利用 lxcfs 來讓容器在資源可見性的行為和虛機保持一致,后續文章會介紹其在Kubernetes上的使用方案。
阿里云Kubernetes服務 全球首批通過Kubernetes一致性認證,簡化了Kubernetes集群生命周期管理,內置了與阿里云產品集成,也將進一步簡化Kubernetes的開發者體驗,幫助用戶關注云端應用價值創新。
原文作者:易立
原文鏈接
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/76345.html
摘要:本系列文章會記錄阿里云容器服務團隊在支持客戶中的一些心得體會和最佳實踐。阿里云服務全球首批通過一致性認證,簡化了集群生命周期管理,內置了與阿里云產品集成,也將進一步簡化的開發者體驗,幫助用戶關注云端應用價值創新。 showImg(https://segmentfault.com/img/bV6FTH?w=740&h=296); 隨著容器技術的成熟,越來越多的企業客戶在企業中選擇Dock...
摘要:簡介社區中常見的做法是利用來提供容器中的資源可見性。從而使得應用獲得正確的資源約束設定。阿里云服務全球首批通過一致性認證,簡化了集群生命周期管理,內置了與阿里云產品集成,也將進一步簡化的開發者體驗,幫助用戶關注云端應用價值創新。 摘要: 這是本系列的第2篇內容,將介紹在Docker和Kubernetes環境中解決遺留應用無法識別容器資源限制的問題。 showImg(https://se...
摘要:同時該版本在安全性和等關鍵功能上作出了改進年月日,發布。盡管谷歌這些年來是的主要貢獻者,但現在其他技術人員在這個項目上的貢獻量已經幾乎和谷歌持平了。這些舉動都在表明云計算市場的戰火將繼續蔓延,已經成為兵家必爭之地。年月日,宣布推出。 Kubernetes 在過去幾年中一直是云計算領域最著名的開源項目之一。20...
摘要:今天是數人云容器三國演義嘉賓演講實錄第四彈。說完了各家容器技術的實戰,那么最后來看容器技術的融合正在探索的一條道路。月,開始接手,因為整個產品都是基于這個為基礎的。下面是的地址,到可以找到相關的資料。但這時候是分開的,不同的使用不同的框架。 今天是數人云容器三國演義Meetup嘉賓演講實錄第四彈。說完了各家容器技術的實戰,那么最后來看容器技術的融合——IBM正在探索的一條道路。 我叫馬...
摘要:今天是數人云容器三國演義嘉賓演講實錄第四彈。說完了各家容器技術的實戰,那么最后來看容器技術的融合正在探索的一條道路。月,開始接手,因為整個產品都是基于這個為基礎的。下面是的地址,到可以找到相關的資料。但這時候是分開的,不同的使用不同的框架。 今天是數人云容器三國演義Meetup嘉賓演講實錄第四彈。說完了各家容器技術的實戰,那么最后來看容器技術的融合——IBM正在探索的一條道路。 我叫馬...
閱讀 1697·2021-10-09 09:44
閱讀 3263·2021-09-27 13:36
閱讀 1520·2021-09-22 15:33
閱讀 1274·2021-09-22 15:23
閱讀 1159·2021-09-06 15:02
閱讀 1695·2019-08-29 16:14
閱讀 2901·2019-08-29 15:26
閱讀 2408·2019-08-28 18:08