背景
- 我們的業務共使用11臺(阿里云)服務器,使用SpringcloudAlibaba構建微服務集群,共計60個微服務,全部注冊在同一個Nacos集群
- 流量轉發路徑: nginx->spring-gateway->業務微服務
- 使用的版本如下:
spring-boot.version:2.2.5.RELEASE
spring-cloud.version:Hoxton.SR3
spring-cloud-alibaba.version:2.2.1.RELEASE
java.version：1.8
案發
- 春節放假期間,收到反饋,網頁報錯服務未找到(gateway找不到服務的報錯提示).
- 查看nacos集群串列,發現個別服務丟失(下線).
- 這個問題每幾天出現一次,出現時間不固定,每次掉線的服務像是隨機選的幾個.
- 服務手動kill+restart后能穩定運行2-3天
排查和解決
懷疑物件一:服務器記憶體爆了
1.進阿里云控制臺查看故障機器近期的各項指標,但是發現故障機器的指標有重要的幾項丟失,記憶體使用率,cpu使用率,系統負載均不顯示
2.控制臺看不了只好進服務器內查看各指標
free -m 查看記憶體,無例外
3.提交阿里工單,授權阿里工程師幫忙修復控制臺顯示問題,懷疑這個問題對業務有影響
4.控制臺修復后掉線問題依然存在
懷疑物件二:CPU滿載
能感覺到執行命令很流暢,所以感覺不是這個原因, top查看后很正常
懷疑物件三:磁盤滿了
雖然概率很小,但是看一下,du -sh *發現磁盤容量還能用到公司倒閉
懷疑物件四:網路有問題
- 服務器那三個基本故障暫時排除后,最大懷疑物件就是網路,畢竟服務掉線肯定是服務端一段時間內接收不到客戶端心跳包,所以把客戶端踢下線了.
- 通過
telnet,mtr -n *.*.*.*,netstat -nat |grep "TIME_WAIT" | wc -l這些命令也只能看個大概. echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse修改內核引數,開啟TIME_WAIT socket復用能力，提升實體的網路發送請求性能.- 查看nacos客戶端(微服務)的日志,在前面案發里提到沒有日志記錄
懷疑物件五:Nacos集群服務端故障
- 查看nacos集群部署的那幾臺服務器,查看服務器基礎指標(記憶體,cpu,磁盤等),未發現例外(畢竟還有幾十個微服務都很正常作業)
- 查看nacos服務端日志,發現確實有主動下線服務操作,那就奇怪了,這個機器上的有些服務還在正常作業,為什么會隨機下線幾個服務呢?
懷疑物件六:微服務占用資源太多
后來仔細想想,這個懷疑物件是不是有點離譜了?因為部署腳本都是同一個,而且負載均衡也是一樣的,但其他機器的這個服務都好好的.
1.調大每個微服務的記憶體占用
2.添加堆疊列印
3.等待一段時間后,例外依然存在,并且,沒有堆疊列印???因為行程好好的并沒退出!
4.google搜索nacos服務掉線,找到一篇看起來極其靠譜的文章!
5.上文提到我使用的springcloud版本,恰好這個版本的nacos-client版本就是1.4.1,于是立馬測驗升級
6.觀察幾天后,發現問題依舊,只能將探查方向繼續轉回微服務本身.
7.使用arthas進行勘測各項指標,發現所有正常的服務各指標均正常.
8.想到服務掉線大概率是因為心跳包丟失,懷疑是心跳執行緒因為某些原因被殺死了.
9.翻看nacos-client原始碼,找到心跳函式(nacos2.x不是這個),使用arthas監聽心跳包,嘗試能找到心跳丟失的證據,貼上當時的記錄
10.當例外再次發生......arthas監聽卡死,無任何記錄和回應........
11.無奈更換思路,寫一個監聽服務掉線的程式,期望可以在作業時間內及時獲取到例外
12.終于在作業時間捕獲到例外,第一時間進入服務器內查看情況,
13.確認服務器基礎項沒問題后,使用arthas查看服務行程堆疊情況,但是arthas無法進入行程!!!
14.用jstat查看GC情況,顯示很正常
15.用jmap/jstack輸出堆疊jstack -l 25944 >heap.txt,但是提示無法進入行程,無奈使用添加-F(這個引數的堆疊少了很多資訊),jstack -F -l 25944 >heap.txt
16.查看堆疊檔案,上萬行記錄,眼都看花了,但是沒有死鎖也沒有發現例外
17.此時發現監聽程式提示服務上線了???!!!檢查后發現確實掉線的幾個微服務自動恢復了,心想這就難排查了.
18.嘗試復現BUG,此時離第一次案發已經過去一周多,必須盡快處理好這個BUG,否則可能得被迫離職了...
19.當第二次發生例外的時候,使用同樣的方式,arthas無法進入->...->jstack輸出堆疊,奇跡發生了,服務又恢復正常了
20.思考/猜測:因為jvm死了(假死),所以導致行程中的一切內容,包括心跳執行緒,日志等,都hold住.
20.Google搜索關鍵詞jvm停止(假死)排查,終于找到一個極其靠譜的回答
21.連忙查看對比使用的幾個機器內核版本號uname -r
22.那個低版本的就是故障機器,確認相關資訊后,聯系阿里云提交工單
23.升級完內核并重啟后機器后,觀察兩天至今,這個問題不存在了,誰能想到這個問題居然是因為Linux內核的BUG引起的,不得不佩服第一個發現這個BUG的大佬
完結感言
這個問題折磨了一周多,每日如鯁在喉!除錯程序也是苦樂參半,樂的是突然有了除錯思路,苦的是思路是一條死胡同,還好最終結果是滿意的.
作為一名程式員,還是要時刻保持一顆探索的心,學海無涯!
2023-02-03 記于深圳
你要是覺得寫的還不錯,就點個關注,可以評論區留下足跡,以后方便查看. 你要是覺得寫的很辣雞,評論區歡迎來對線! 歡迎轉載!轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/542928.html
標籤：其他
上一篇：為啥要對jvm做優化？