2020.10.24故障分析与思考

前言

时隔一周，万万没有想到有除了一个严重的线上问题，10.24 晚上21点的时候，出现大量的用户请求超时，真是个悲剧呀。

故障回顾

1）故障描述

24号20:58分开始，有老师和学生反馈直播间出现卡死现象，之后有同学反馈作业无法提交。页面提示advisor.estudy.cn 网关处理请求异常，请联系管理员！

2）故障过程回顾

时间	过程
10.24 20:58	有老师和学生反馈直播间出现卡死现象
10.24 21:05	出现大面积老师和学生反馈直播间卡死崩溃，页面报错：advisor.estudy.cn 网关处理请求异常，请联系管理员！
10.24 21:07	查看系统所有的接口都出现大面积超时
10.24 21:17	部分用户已正常，部分用户仍有问题
10.24 21:25	应用扩容，问题修复

故障思考

系统

这个问题相对比较明显一些，就是应用资源不足的问题，我们用户量从5W在线变成了7W在线，导致应用资源不足。
分析过程如下
1、我们通过我们的监控发现大量的请求超时。

请求超时

2、还有就是我们的应用出现crash的报警，大量的容器出现重启的现象。

Evicated

3、通过K8S的日志可以发现，由于内存不足导致容器的强制重启。

应用

那么，为什么会出现内存不足的情况呢？
先了解一些比较简单的知识点：
1、k8s分配的内存是有上限的，我们配置的上限是4G
2、JVM进程内存=堆内存+线程栈+堆外内存+代码区+其他
3、我们采用的dubbo线程池方式为fixed，固定大小线程池
4、线程线大小默认1M，可以由-Xss参数修改

image.png

因此，根据线程数，最大占用的数量有可能为1425M。
我们的应用，占用内存=堆内存(3g)+堆外(192M)+线程栈(1M*1425)最大约为4.5g
因此是我们配置的内存限制太小了。
因此解决方案很简单，减少dubbo线程池fixed的数量就好了

人员与管理

整体全部容器化之后，很少在系统的极限压力下面对系统进行测试，有必要进行这样的测试，分析整体系统的稳定性。