大家好，我是烤鴨：

?????最近線上問題有點多啊，分享一個服務假死的排查過程。

問題描述

9點10分，收到進程無響應報警(一共6臺機器，有1臺出現)，后來又有1臺出現。

排查思路

首先確認是否誤報或者網絡抖動，登陸服務器查看進程存在。

查看cat監控，發現gc次數和gc耗時都升高，基本確認是oom導致的。

當時由于優先處理問題，服務重啟后，沒辦法找到oom源頭了(進程命令包含oom記錄，但是沒生成oom日志)。

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/

jvm 參數：

jvm_args: -Xms8g -Xmx8g -Xmn4g -Xss256k -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -Dlog4j2.formatMsgNoLookups=true -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:InitiatingHeapOccupancyPercent=45 -XX:G1MixedGCLiveThresholdPercent=65 -XX:MaxTenuringThreshold=10 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/ -XX:ErrorFile=/data/logs/hs_err_%p.error -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=100M -Xloggc:/data/logs/gc.gclog -XX:-OmitStackTraceInFastThrow

但是生成了error日志(hs_err_%p.erro)。其中的Core dump文件生成是有條件,一般Linux是關掉的.可以通過 ulimit -a 這個命令進行查看。

# # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 8589934592 bytes for committing reserved memory. # Possible reasons: # The system is out of physical RAM or swap space # In 32 bit mode, the process size limit was hit # Possible solutions: # Reduce memory load on the system # Increase physical memory or swap space # Check if swap backing store is full # Use 64 bit Java on a 64 bit OS # Decrease Java heap size (-Xmx/-Xms) # Decrease number of Java threads # Decrease Java thread stack sizes (-Xss) # Set larger code cache with -XX:ReservedCodeCacheSize= # This output file may be truncated or incomplete. # # Out of Memory Error (os_linux.cpp:2627), pid=13887, tid=0x00007ff3239f9700 # # JRE version: (8.0_111-b14) (build ) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.111-b14 mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again #

后來下午又出現了，dump出來了gc日志，通過工具分析(jprofiler)。

可以看出String和charp[]加起來就5G多了。

后來又看了下String和char[]，基本就是字段名稱?；揪褪谴_定是大對象導致的問題，最后查一下大對象是哪個中間件返回的。(mongo、redis、db、es)

找到一個業務對象，查一下引用，發現是mongo查詢導致的。

根因分析

代碼運行很長時間都沒有問題，為什么會出現oom。

后來發現上游分頁參數的page太大了，導致這個問題。

雖然是惡意請求，不過也應該盡量避免這種問題。(參數為空或者數值過大，都應該限制下)

總結

以上是生活随笔為你收集整理的记一次线上服务假死排查过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。