生产问题排查手册.md · alan-tang-tt/product-issue

# 生产问题排查手册

## 1. 磁盘满了

现象：应用卡顿、但是进程没挂，系统也没挂，就是非常卡。

```shell
df -h

du -h --max-depth=2 /

du --block-size=MB --max-depth=2 |sort -k1 -n -r |head -n5

ls -lhS /xxx
```

## 2. 用户无法连接

现象：Error: open too many files

```shell
1. ulimit –n
2. ulimit –n 65535（临时）
3. vim /etc/security/limits.conf（永久）
* soft nofile 65535
* hard nofile 65535
```

TIME_WAIT & CLOSE_WAIT

```
1. 统计命令
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
2. TIME_WAIT
主动关闭方，可调整等待时间。
3. CLOSE_WAIT
修改程序，自定义发送心跳。
```

## 3. CPU飙高

现象： 系统卡顿，没挂，能用，就是慢。

```shell
top
top –H –p <pid>
jstack <pid> | grep <tid> -A 10
yum install -y java-1.8.0-openjdk-devel.x86_64
```

## 4. 堆内存溢出

现象： 系统可能挂了，也可能没挂，但是，基本上所有的接口都返回内部服务器错误。

报错： java.lang.OutOfMemoryError: Java heap space

```shell
# JVM启动参数
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/app/applogs/heapdump
# 命令
jmap -dump:format=b,file=heapdump.phrof pid
```

## 5. 元空间溢出

现象：日志中报错， java.lang.OutOfMemoryError: Metaspace

```
# 1. 先元空间的大小改大一些
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m
# 2. 检测有没有错误的参数
-XX:SoftRefLRUPolicyMSPerMB=1000 # 默认就是1000ms，不要动这个参数
# 3. 检测是不是我们的代码或者第三方的框架频繁创建了太多的代理类，而且没有使用缓存
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(BusinessServiceImpl.class);
enhancer.setUseCache(true); # false就会引起元空间溢出
```

## 6. 直接内存溢出

现象：

```
1. 报错：java.lang.OutOfMemoryError: Direct buffer error
2. 报错：io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 1024 byte(s) of direct memory (used: 101815, max: 102400)
```

场景：

```
1. netty的ByteBuf没有完全释放：
    io.netty.util.ReferenceCountUtil#retain(T)
    io.netty.util.ReferenceCountUtil#release(java.lang.Object)

2. 封闭了ByteBuf的类没有完全释放：
    org.springframework.core.io.buffer.DataBufferUtils#retain(T)
    org.springframework.core.io.buffer.DataBufferUtils#release(DataBuffer)

3. Jar包不兼容
```

排查思路（Netty直接内存溢出）：

```
1. 本地调试；
2. 增加监控：PlatformDependent.usedDirectMemory();
3. 修改参数：-Dio.netty.allocator.type=unpooled -Dio.netty.leakDetection.level=PARANOID
4. 排除法：
（1）把自己写的类注释掉，看会不会再有直接内存溢出；
（2）如果还有，说明是框架代码有问题；
（3）如果没有了，说明是自己代码有问题；
5. linux系统使用pmap、gdb等工具排查；
```

案例：

```
https://gitee.com/alan-tang-tt/springcloud-gateway-oom.git
```

## 7. 线程栈溢出

现象：

```
1. 报错：java.lang.StackOverFlowError
2. 有的请求有问题，有的请求没问题，即使是同样的接口同样的参数
3. 程序运行一段时间后出现问题，之后就一直有问题
4. 返回错误信息时有问题，返回正常值时没问题
```

排查思路：

```
1. 查看日志：找到无限递归的进入点，及出现无限递归时的参数。
2. 本地调试：模拟无限递归的场景。
```

## 8. 频繁的Full GC

现象：

```
1. 频繁Full GC，系统经常卡顿；
2. 一般来说，CPU会有明显地升高，甚至达到100%，如果使用jstack去看线程栈的情况，会发现GC线程一直占用着CPU；
3. 一般来说，不会出现堆内存溢出；
```

排查思路：

```
1. 添加GC参数：-XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:./gclogs.log
2. 检查GC日志：看有没有大量的System.gc()相关的字样，如果有的话，说明是代码里面或者公共组件或者框架里面显式地使用了System.gc()导致的Full GC，这种情况考虑系统有没有大量使用到直接内存，如果没有的话，添加-XX:+DisableExplicitGC参数可解决；
3. 检查JVM参数：是否因为新生代设置过小导致了大量对象进入老年代，从而触发了Full GC；
```

JVM参数模板（基于JDK8）：

建议：新生代 : 老年代 = 2 : 1（或 1 : 1）

```
-server -Xmx4g -Xms4g -Xmn2g -Xss1m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -XX:-UseGCOverheadLimit -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=92 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:-PrintConcurrentLocks -XX:+PrintTenuringDistribution -XX:HeapDumpPath=/app/applogs/heapdump -Xloggc:/app/applogs/gc.log
```

alan-tang-tt/product-issue

简介

发行版

贡献者

近期动态

alan-tang-tt/product-issue .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

alan-tang-tt/product-issue