前言
时隔一周，万万没有想到有除了一个严重的线上问题，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的数量就好了
人员与管理
整体全部容器化之后，很少在系统的极限压力下面对系统进行测试，有必要进行这样的测试，分析整体系统的稳定性。
