大家好，我是烤鴨：

?????最近線上問題有點(diǎn)多啊，分享一個(gè)服務(wù)假死的排查過程。

問題描述

9點(diǎn)10分，收到進(jìn)程無響應(yīng)報(bào)警(一共6臺(tái)機(jī)器，有1臺(tái)出現(xiàn))，后來又有1臺(tái)出現(xiàn)。

排查思路

首先確認(rèn)是否誤報(bào)或者網(wǎng)絡(luò)抖動(dòng)，登陸服務(wù)器查看進(jìn)程存在。

查看cat監(jiān)控，發(fā)現(xiàn)gc次數(shù)和gc耗時(shí)都升高，基本確認(rèn)是oom導(dǎo)致的。

當(dāng)時(shí)由于優(yōu)先處理問題，服務(wù)重啟后，沒辦法找到oom源頭了(進(jìn)程命令包含oom記錄，但是沒生成oom日志)。

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

jvm 參數(shù)：

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是關(guān)掉的.可以通過 ulimit -a 這個(gè)命令進(jìn)行查看。

# # 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 #

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

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

后來又看了下String和char[]，基本就是字段名稱。基本就是確定是大對(duì)象導(dǎo)致的問題，最后查一下大對(duì)象是哪個(gè)中間件返回的。(mongo、redis、db、es)

找到一個(gè)業(yè)務(wù)對(duì)象，查一下引用，發(fā)現(xiàn)是mongo查詢導(dǎo)致的。

根因分析

代碼運(yùn)行很長(zhǎng)時(shí)間都沒有問題，為什么會(huì)出現(xiàn)oom。

后來發(fā)現(xiàn)上游分頁參數(shù)的page太大了，導(dǎo)致這個(gè)問題。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。