一、進(jìn)入docker容器的宿主機(jī)，查看運(yùn)行指定鏡像的容器id（結(jié)果的第一列）：
docker ps | grep myImageName（或docker ps | grep java）
二、進(jìn)入容器內(nèi)部：
docker exec -it containerId sh
三、直接輸入top命令：
top
可看到基本的容器占用的信息：pid、vsz、cpu、command等。（ctrl+c 或 q，退出top）
四、查看更具體的jvm內(nèi)存占用：
其中，vsz：Virtual Memory Size，虛擬內(nèi)存大小，表明了該進(jìn)程可以訪問(wèn)的所有內(nèi)存，包括被交換的內(nèi)存和共享庫(kù)內(nèi)存。
rss： Resident Set Size，常駐內(nèi)存集合大小，表示進(jìn)程在RAM中占用了多少內(nèi)存，并不包含在SWAP中占用的虛擬內(nèi)存。即使是在內(nèi)存中的使用了共享庫(kù)的內(nèi)存大小也一并計(jì)算在內(nèi)，包含了完整的在stack和heap中的內(nèi)存。
SHR：shared memory，共享內(nèi)存。
補(bǔ)充：
ps -ef | grep java 或 docker top 容器id ，可查看pid的一些信息。
ps aux | grep java。
top -p pid。
RSS 是常駐內(nèi)存集（Resident Set Size），表示該進(jìn)程分配的內(nèi)存大小。
RSS 不包括進(jìn)入交換分區(qū)的內(nèi)存。
RSS 包括共享庫(kù)占用的內(nèi)存（只要共享庫(kù)在內(nèi)存中）
RSS 包括所有分配的棧內(nèi)存和堆內(nèi)存。
VSZ 表示進(jìn)程分配的虛擬內(nèi)存。
VSZ 包括進(jìn)程可以訪問(wèn)的所有內(nèi)存，包括進(jìn)入交換分區(qū)的內(nèi)容，以及共享庫(kù)占用的內(nèi)存。
VSZRW：未百度到具體含義，猜測(cè)：初始申請(qǐng)的虛擬內(nèi)存大小。
docker stats 容器名 或 docker stats 容器id，結(jié)果如下：
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
補(bǔ)充：docker容器化下的JVM參數(shù)調(diào)優(yōu)
1、JVM堆內(nèi)存設(shè)置
跑在docker容器的Java服務(wù)發(fā)生過(guò)幾次內(nèi)存超標(biāo)異常，實(shí)際上這和Java程序的docker容器化有很大的關(guān)系。Java和docker并不是天然的朋友，docker可以設(shè)置內(nèi)存和CPU限制，底層通過(guò)Linux cgroup技術(shù)實(shí)現(xiàn)，但是Java JVM并不能自動(dòng)檢測(cè)到。
我們可以使用Java的Xmx標(biāo)識(shí)手動(dòng)指定堆內(nèi)存的大小或者使用較高版本的JDK提供的JVM標(biāo)識(shí)，解決這個(gè)問(wèn)題。
問(wèn)題：
舊版本Java8(update 131之前的版本)，JVM的可用內(nèi)存和CPU數(shù)量并不是docker允許你使用的可用內(nèi)存和CPU數(shù)量
比如docker容器中限制只能使用1G,但是舊版本Java并不能識(shí)別到這個(gè)限制，當(dāng)業(yè)務(wù)增長(zhǎng)時(shí)，JVM就會(huì)申請(qǐng)更多內(nèi)存，可能遠(yuǎn)超這個(gè)限制。但是如果使用太多內(nèi)存，docker就會(huì)采取行動(dòng)并殺死容器內(nèi)的Java進(jìn)程，顯然這不是我們想要的！
目前我們生產(chǎn)環(huán)境使用Java8版本，這個(gè)問(wèn)題可通過(guò)-Xmx限制堆內(nèi)存大小來(lái)解決，不過(guò)這里實(shí)際限制了兩次，一次是docker容器的內(nèi)存限制，一次是jvm堆內(nèi)存的限制。
解決方法：
這個(gè)前提需要Java程序的dockerfile支持：
# 初始鏡像
FROM adoptopenjdk/openjdk8
# jar包名字需要更改為項(xiàng)目名字-版本號(hào)，后面app.jar 不變
ADD example-sun-1.0.jar app.jar
# 配置JVM啟動(dòng)參數(shù)
ENV JVM_ARGS=${JVM_ARGS}
EXPOSE 8080
# 優(yōu)化jvm參數(shù)配置啟動(dòng)
ENTRYPOINT java ${JVM_ARGS} -Djava.security.egd=file:/dev/./urandom -jar app.jar
具體在k8s deployment.yaml 部署文件中環(huán)境變量 env 中加入以下參數(shù)，當(dāng)JVM 啟動(dòng)時(shí)就會(huì)加載進(jìn)去
- name: JVM_ARGS
value: -Xmx1024m -Xms512m
Xmx1024m #設(shè)置jvm堆內(nèi)存的最大值
-Xms512m #設(shè)置jvm堆內(nèi)存的最小值
這里設(shè)置最小堆內(nèi)存為512m,最大內(nèi)存為1024m, 堆內(nèi)存調(diào)整不要一味簡(jiǎn)單增大，要仔細(xì)分析內(nèi)存占用過(guò)大的原因，是否有代碼上的問(wèn)題。
較高版本Java9之后（8u131+）JVM提供更好的解決方式
使用JVM 標(biāo)志： -XX:+UnlockExperimentalVMOptions-XX:+UseCGroupMemoryLimitForHeap
強(qiáng)制JVM檢查L(zhǎng)inux的cgoup配置，實(shí)際上docker正是通過(guò)Linux的cgroup技術(shù)來(lái)限制容器的內(nèi)存等資源的?，F(xiàn)在如果應(yīng)用達(dá)到了docker設(shè)置的限制（比如1G）,JVM是可以看到這個(gè)限制的，JVM就會(huì)嘗試GC操作。
如果gc之后仍然超過(guò)內(nèi)存限制，那JVM就會(huì)做它該做的事情，比如拋出OutOfMemoryException.也就是說(shuō)，JVM能夠識(shí)別到docker的這些設(shè)置。
2、GC日志打印以及OOM自動(dòng)dump
程序運(yùn)行過(guò)程中，也可以打印GC日志，方便排查問(wèn)題， 同時(shí)當(dāng)Java發(fā)生OutOfMemory 異常時(shí)可將heap 內(nèi)存 dump 下來(lái)方便我們排查問(wèn)題使用，設(shè)置以下參數(shù)：
- name: JVM_ARGS
value: -Xmx1536m -Xms512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/my-heap-dump.hprof -Xloggc:/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps
參數(shù)含義：
# 發(fā)生內(nèi)存溢出自動(dòng)dump內(nèi)存文件
-XX:+HeapDumpOnOutOfMemoryError
############ 指定dump文件地址為服務(wù)打印日志文件夾/logs（已掛載）
-XX:HeapDumpPath=/logs/my-heap-dump.hprof
############ 打印服務(wù)gc日志
-Xloggc:/logs/gc.log
# 輸出詳細(xì)GC日志
-XX:+PrintGCDetails
# 格式化輸出時(shí)間戳 2020-09-17T19:45:05.680+0800
-XX:+PrintGCDateStamps
以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。
