记一次线上服务假死排查过程

大家好，我是烤鸭：

     最近线上问题有点多啊，分享一个服务假死的排查过程。

问题描述

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太大了，导致这个问题。

虽然是恶意请求，不过也应该尽量避免这种问题。(参数为空或者数值过大，都应该限制下)