前言
時隔一周，萬萬沒有想到有除了一個嚴重的線上問題，10.24 晚上21點的時候，出現(xiàn)大量的用戶請求超時，真是個悲劇呀。
故障回顧
1）故障描述
24號20:58分開始，有老師和學(xué)生反饋直播間出現(xiàn)卡死現(xiàn)象，之后有同學(xué)反饋作業(yè)無法提交。頁面提示advisor.estudy.cn 網(wǎng)關(guān)處理請求異常，請聯(lián)系管理員！
2）故障過程回顧
| 時間 | 過程 |
|---|---|
| 10.24 20:58 | 有老師和學(xué)生反饋直播間出現(xiàn)卡死現(xiàn)象 |
| 10.24 21:05 | 出現(xiàn)大面積老師和學(xué)生反饋直播間卡死崩潰，頁面報錯：advisor.estudy.cn 網(wǎng)關(guān)處理請求異常，請聯(lián)系管理員！ |
| 10.24 21:07 | 查看系統(tǒng)所有的接口都出現(xiàn)大面積超時 |
| 10.24 21:17 | 部分用戶已正常，部分用戶仍有問題 |
| 10.24 21:25 | 應(yīng)用擴容，問題修復(fù) |
故障思考
系統(tǒng)
這個問題相對比較明顯一些，就是應(yīng)用資源不足的問題，我們用戶量從5W在線變成了7W在線，導(dǎo)致應(yīng)用資源不足。
分析過程如下
1、我們通過我們的監(jiān)控發(fā)現(xiàn)大量的請求超時。
2、還有就是我們的應(yīng)用出現(xiàn)crash的報警，大量的容器出現(xiàn)重啟的現(xiàn)象。
3、通過K8S的日志可以發(fā)現(xiàn)，由于內(nèi)存不足導(dǎo)致容器的強制重啟。
應(yīng)用
那么，為什么會出現(xiàn)內(nèi)存不足的情況呢？
先了解一些比較簡單的知識點：
1、k8s分配的內(nèi)存是有上限的，我們配置的上限是4G
2、JVM進程內(nèi)存=堆內(nèi)存+線程棧+堆外內(nèi)存+代碼區(qū)+其他
3、我們采用的dubbo線程池方式為fixed，固定大小線程池
4、線程線大小默認1M，可以由-Xss參數(shù)修改
因此，根據(jù)線程數(shù)，最大占用的數(shù)量有可能為1425M。
我們的應(yīng)用，占用內(nèi)存=堆內(nèi)存(3g)+堆外(192M)+線程棧(1M*1425)最大約為4.5g
因此是我們配置的內(nèi)存限制太小了。
因此解決方案很簡單，減少dubbo線程池fixed的數(shù)量就好了
人員與管理
整體全部容器化之后，很少在系統(tǒng)的極限壓力下面對系統(tǒng)進行測試，有必要進行這樣的測試，分析整體系統(tǒng)的穩(wěn)定性。
