docker應用，後端服務出現OOM狀況排查

參考：

https://qingmu.io/2018/12/17/How-to-securely-limit-JVM-resources-in-a-container/#more

 

 

默認狀況下，JVM的Max Heap Size是系統內存的1/4，假如咱們系統是8G，那麼JVM將的默認Heap≈2G。

 

# docker logs compose_cwtpro-back_1

Exception in thread "http-nio-8080-Acceptor-0" java.lang.OutOfMemoryError: GC overhead limit exceeded

28-Feb-2019 08:59:19.035 SEVERE [http-nio-8080-ClientPoller-0] org.apache.tomcat.util.net.NioEndpoint$Poller.events

java.lang.OutOfMemoryError: GC overhead limit exceeded

 

Exception in thread "http-nio-8080-exec-89" java.lang.OutOfMemoryError: GC overhead limit exceeded

Exception in thread "http-nio-8080-exec-58" java.lang.OutOfMemoryError: GC overhead limit exceeded

Exception in thread "http-nio-8080-exec-123" java.lang.OutOfMemoryError: GC overhead limit exceeded

 

# docker exec -it compose_cwtpro-back_1 bash

# java  -XshowSettings:vm  -version

 

 

從監控頁面獲取的信息是，在故障時間點，後端業務的內存使用量忽然飆升到接近4.3G，所以致使OOM

 

設置參數：

JAVA_OPTS="-server -Xms6g -Xmx6g -XX:PermSize=256m -XX:MaxPermSize=512m -XX:-OmitStackTraceInFastThrow"      //因爲compose文件裏面沒有聲明相關jvm參數，所以採用默認。致使初始最大堆棧爲系統內存的1/4（4G）。最終忽然的流量上升，致使OOM。

 

驗證設置是否有效：

# docker exec -it 2f24707d7a97 bash

# ps -ef | grep java

# jinfo -flag MaxHeapSize 7   //打印對應pid的最大堆棧

 

對比主91.17，設置未重啓及JAVA_OPTS未生效的：

3.87G 基本與截圖一中經過java  -XshowSettings:vm  -version獲取的最大堆棧符合（容器啓動未限制容器可以使用內存，默認讀取/proc/meminfo爲最大能夠內存，未設置docker啓動限制cpu及內存狀況下，默認MaxHeapSize爲可用最大內存的1/4）

 

 

查看堆內存中的對象數目、大小統計直方圖，若是帶上live則只統計活對象，以下：

# jmap -histo:live 26590 | less

 

用jmap把進程內存使用狀況dump到文件中，再用jhat分析查看。jmap進行dump命令格式以下：

# jmap -dump:format=b,file=/tmp/v2x_dump 7

//拷貝出來

kubectl cp  deploy--user-6ff76fdbcf-cmdgh:/application/map_dump /root