博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
故障排查:是什么 导致了客户端批量心跳超时掉线(转)
阅读量:5861 次
发布时间:2019-06-19

本文共 1110 字,大约阅读时间需要 3 分钟。

 

故障排查:是什么 导致了客户端批量心跳超时掉线

心跳超时指的是:针对某个在线的客户端(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

 

你可能感兴趣的文章
除了模拟手术教学,VR在医疗领域如何应用?
查看>>
盘点5款Ubuntu监控工具解决CPU暴增问题
查看>>
java 测试IP
查看>>
用CSS做导航菜单的4个理由
查看>>
NOIP2015 运输计划 二分答案+Tarjan LCA+树上差分
查看>>
构建之法读后感
查看>>
基本信息项目目标文档
查看>>
移动开发Html 5前端性能优化指南
查看>>
silverlight style和template 使用之tip
查看>>
Eclipse配置python环境
查看>>
第十二周总结
查看>>
Import declarations are not supported by current JavaScript version--JavaScript版本不支持导入声明...
查看>>
js兼容性大全
查看>>
晶振不起振的原因及其解决方法
查看>>
学习目标
查看>>
《利用python进行数据分析》学习笔记--数据聚合与分组(groupby)
查看>>
C++中的函数指针模板
查看>>
2015年个人总结
查看>>
C#编程(六)------------枚举
查看>>
《系统架构师》——操作系统和硬件基础
查看>>