背景
運(yùn)行在 Docker 容器中的 Java 應(yīng)用經(jīng)常會(huì)被操作系統(tǒng) kill注竿,但 JVM 沒有 OOM 日志,下面是一個(gè) Java 應(yīng)用的容器因?yàn)槌^了 cgroup 的限制被 kill:
# dmesg -T
[Sun Mar 22 10:26:23 2020] Memory cgroup out of memory: Kill process 25086 (java) score 1838 or sacrifice child
[Sun Mar 22 10:26:23 2020] Killed process 25086 (java) total-vm:12040204kB, anon-rss:3705828kB, file-rss:23472kB
為什么設(shè)置了 -Xmx 還是被 kill
根據(jù) JDK1.8 的特點(diǎn)虚缎,JVM 運(yùn)行時(shí)的內(nèi)存 = 非heap(元空間 + Thread Stack * num of thread + ...) + heap + JVM進(jìn)程運(yùn)行所需內(nèi)存 + 其他數(shù)據(jù)蓝撇,我們設(shè)置的 -Xmx
等參數(shù)只是限制了 JVM 堆內(nèi)存(heap) 的大小,當(dāng) -Xmx
設(shè)置的值接近與容器限制的值叙淌,堆內(nèi)存 + 非堆內(nèi)存的使用總和超出了 cgroup 的限制就會(huì)被操作系統(tǒng) kill 掉市咆。
讓 JVM 動(dòng)態(tài)感知 cgroup
如果沒有設(shè)置堆內(nèi)存的大小汉操,默認(rèn)情況下,JVM 的 Max Heap Size 是操作系統(tǒng)的 1/4床绪,我們知道 Docker 是通過 CGroups 來實(shí)現(xiàn)內(nèi)存的限制客情,而 /proc
目錄只是以只讀的形式掛載到容器中,默認(rèn)情況下 Java 是看不到 CGroups 限制的內(nèi)存大小癞己,而是通過 /proc/meminfo
中的信息作為內(nèi)存信息啟動(dòng)膀斋,這種不兼容的情況就會(huì)導(dǎo)致,容器分配的內(nèi)存小于JVM Max Heap Size 的情況痹雅。
操作系統(tǒng)的內(nèi)存信息:
/ $ [ec2-user@ip-172-29-165-49 ~]$ cat /proc/meminfo
MemTotal: 31960240 kB
MemFree: 233200 kB
MemAvailable: 4412724 kB
Docker 容器讀取到的內(nèi)存信息:
[ec2-user@ip-172-29-165-49 ~]$ docker run -it --rm alpine cat /proc/meminfo
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
89d9c30c1d48: Pull complete
Digest: sha256:c19173c5ada610a5989151111163d28a67368362762534d8a8121ce95cf2bd5a
Status: Downloaded newer image for alpine:latest
MemTotal: 31960240 kB
MemFree: 278460 kB
MemAvailable: 4351520 kB
Java 8u131及以上版本開始支持了Docker的cpu和memory限制仰担。 在 java8u131+ 及 java9,需要加上 -XX:+UnlockExperimentalVMOptions
-XX:+UseCGroupMemoryLimitForHeap
就能使 JVM 感知到對容器的內(nèi)存限制了绩社。
不過在 Java11 中移除了 UseCGroupMemoryLimitForHeap
摔蓝,而增加了一個(gè) bool UseContainerSupport = true
的參數(shù)。
版本 | -XX:+UseCGroupMemoryLimitForHeap | -XX:ActiveProcessorCount | -XX:+UseContainerSupport |
---|---|---|---|
java9 | experimental愉耙,默認(rèn)false | 無 | 無 |
java10 | experimental贮尉,默認(rèn)false | -1 | 無 |
java11 | 移除 | -1 | product,默認(rèn)true |
如何優(yōu)化
雖然 JVM 能夠動(dòng)態(tài)感知 CGroups 對容器的內(nèi)存限制了朴沿,但是 JVM 默認(rèn)的堆大小是限制值的 1/4猜谚,這會(huì)導(dǎo)致內(nèi)存的利用率太低了败砂;如此看來,要想充分利用服務(wù)器的資源魏铅,還要手動(dòng)調(diào)整好 -Xmx 參數(shù)昌犹,下面是來自網(wǎng)絡(luò)的一組經(jīng)驗(yàn)值:
以下參數(shù)配置適用于非計(jì)算密集型的大部分應(yīng)用
分配內(nèi)存 | 堆配置推薦 |
---|---|
1.5G | -Xmx1008M -Xms1008M -Xmn336M -XX:MaxMetaspaceSize=128M -XX:MetaspaceSize=128M |
2G | -Xmx1344M -Xms1344M -Xmn448M -XX:MaxMetaspaceSize=192M -XX:MetaspaceSize=192M |
3G | -Xmx2048M -Xms2048M -Xmn768M -XX:MaxMetaspaceSize=256M -XX:MetaspaceSize=256M |
4G | -Xmx2688M -Xms2688M -Xmn960M -XX:MaxMetaspaceSize=256M -XX:MetaspaceSize=256M |
5G | -Xmx3392M -Xms3392M -Xmn1216M -XX:MaxMetaspaceSize=512M -XX:MetaspaceSize=512M |
6G | -Xmx4096M -Xms4096M -Xmn1536M -XX:MaxMetaspaceSize=512M -XX:MetaspaceSize=512M |
7G | -Xmx4736M -Xms4736M -Xmn1728M -XX:MaxMetaspaceSize=512M -XX:MetaspaceSize=512M |
8G | -Xmx5440M -Xms5440M -XX:MaxMetaspaceSize=512M -XX:MetaspaceSize=512M |
內(nèi)存>=8G 基礎(chǔ)配置
-server
-XX:+DisableExplicitGC
-XX:+UseG1GC
-XX:MaxGCPauseMillis=100
-XX:+ParallelRefProcEnabled
-XX:+HeapDumpOnOutOfMemoryError
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCDateStamps
-XX:ErrorFile=/var/app/gc/hs_err_pid%p.log
-XX:HeapDumpPath=/var/app/gc
-Xloggc:/var/app/gc/gc%t.log
內(nèi)存<8G 基礎(chǔ)配置
-server
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
-XX:+CMSClassUnloadingEnabled
-XX:+ParallelRefProcEnabled
-XX:+CMSScavengeBeforeRemark
-XX:+HeapDumpOnOutOfMemoryError
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCDateStamps
-XX:ErrorFile=/var/app/gc/hs_err_pid%p.log
-XX:HeapDumpPath=/var/app/gc
-Xloggc:/var/app/gc/gc%t.log