故障排查：是什麼 導致了用戶端批量心跳逾時掉線(轉)

標籤：

 

故障排查：是什麼 導致了用戶端批量心跳逾時掉線
心跳逾時指的是：針對某個線上的用戶端（TCP串連），ESFramework服務端在指定的時間內，沒有收到來自該用戶端的任何訊息，則認為該用戶端已經掉線。
 
為什麼需要心跳機制了？因為針對某些用戶端掉線（可能是因為網路斷開、或用戶端程式退出），服務端不能立即感受到（有的可能需要過很長的時間才能感受到），所以，需要引入心跳機制，讓服務端儘可能早地發現用戶端已經不線上了。關於心跳機制，更詳細的介紹可以參見這裡。
 
如果發生了很多用戶端批量心跳逾時掉線的情況，就說明服務端在過去的某段時間內，從未收到來自這些用戶端的任何心跳訊息。通常有3種可能性導致該情況發生：
 
1.CPU或記憶體使用量率過高
 
在該情況發生時，觀察一下服務端進程的CPU和記憶體是否有異常。
比如，當CPU持續在100%時，就有可能導致接收資料的操作被停止。
 
2.處理某些資訊所花費的時間過長
如果服務端的資訊處理模型設定的是IocpDirectly，那麼依據IocpDirectly的原理，當處理某個資訊所花費的時間超過了服務端設定的心跳逾時的時間，服務端就會將對應的用戶端誤判為心跳逾時掉線。
 
假設是該原因導致的心跳逾時，則對應的解決方案有：
 （1）找出那些處理非常耗時的資訊，進行最佳化理，加快處理速度。
 （2）將逾時時間間隔設定位一個更大的值或關閉心跳檢測。
 （3）將資訊處理修改為非同步模式。
 （4）將服務端資訊處理模型修改為TaskQueue模式，這樣就完全避免了由於資訊處理時間過長導致誤判的情況。
 很顯然，方案（1）是最好的也是根本性的解決方案。
 
3.伺服器網路拓撲結構、防火牆、路由器、網路安全監控等相關軟硬體
如果排除了前面的可能性（比如，即使改成了TaskQueue模式，批量掉線仍然發生），那麼，幾乎就只剩下一個可能：服務端在心跳逾時時間間隔內未收到來自這些用戶端的任何訊息。很可能來自用戶端的訊息被防火牆、路由器、或某些網路完全監控的相關軟硬體給擋住了。
 
此時，需要專業的營運人員或網管人員參與進來，協助排查問題，比如：
 （1）在伺服器上執行netstat命令，查看目標連接埠的相關狀態資訊。
 （2）在伺服器上執行抓包工具，監測目標連接埠上是否有資料從用戶端過來。
 （3）分析伺服器的網路拓撲結構，並以伺服器為中心，依次向外檢查防火牆、路由器、網路安全監控等相關軟硬體等的設定，並進行針對性的排查測試。
 
經過以上的排查分析，應該都可以找到問題的根源所在，如果還是沒有結果，可以給我留言，我們一起討論下啊。  

http://www.cnblogs.com/zhuweisky/p/4401435.html

 

故障排查：是什麼 導致了用戶端批量心跳逾時掉線(轉)