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

心跳超时指的是:针对某个在线的客户端(TCP连接),服务端在指定的时间内,没有收到来自该客户端的任何消息,则认为该客户端已经掉线。

为什么需要心跳机制了?因为针对某些客户端掉线(可能是因为网络断开、或客户端程序退出),服务端不能立即感受到(有的可能需要过很长的时间才能感受到),所以,需要引入心跳机制,让服务端尽可能早地发现客户端已经不在线了。关于心跳机制,更详细的介绍可以参见这里

如果发生了很多客户端批量心跳超时掉线的情况,就说明服务端在过去的某段时间内,从未收到来自这些客户端的任何心跳消息。通常有3种可能性导致该情况发生:

1.CPU或内存使用率过高

在该情况发生时,观察一下服务端进程的CPU和内存是否有异常。

比如,当CPU持续在100%时,就有可能导致接收数据的操作被停止。

2.处理某些信息所花费的时间过长

如果服务端的信息处理模型设定的是IocpDirectly,那么依据IocpDirectly的原理,当处理某个信息所花费的时间超过了服务端设定的心跳超时的时间,服务端就会将对应的客户端误判为心跳超时掉线。

假设是该原因导致的心跳超时,则对应的解决方案有:

(1)找出那些处理非常耗时的信息,进行优化理,加快处理速度。

(2)将超时时间间隔设定位一个更大的值或关闭心跳检测。

(3)将信息处理修改为异步模式。

(4)将服务端信息处理模型修改为TaskQueue模式,这样就完全避免了由于信息处理时间过长导致误判的情况。

很显然,方案(1)是最好的也是根本性的解决方案。

3.服务器网络拓扑结构、防火墙、路由器、网络安全监控等相关软硬件

如果排除了前面的可能性(比如,即使改成了TaskQueue模式,批量掉线仍然发生),那么,几乎就只剩下一个可能:服务端在心跳超时时间间隔内未收到来自这些客户端的任何消息。很可能来自客户端的消息被防火墙、路由器、或某些网络完全监控的相关软硬件给挡住了。

此时,需要专业的运维人员或网管人员参与进来,协助排查问题,比如:

(1)在服务器上执行netstat命令,查看目标端口的相关状态信息。

(2)在服务器上执行抓包工具,监测目标端口上是否有数据从客户端过来。

(3)分析服务器的网络拓扑结构,并以服务器为中心,依次向外检查防火墙、路由器、网络安全监控等相关软硬件等的设定,并进行针对性的排查测试。

经过以上的排查分析,应该都可以找到问题的根源所在,如果还是没有结果,可以给我留言,我们一起讨论下啊。

时间: 2024-10-17 02:09:11

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

kafka故障排查-consumer处理超时导致的异常

最近遇到一个kafka方面的问题,大致就是由于consumer处理业务超时,导致无法正常提交Offset,进而导致无法消费新消息的问题.下面我想从以下几个方面对此次故障排查进行复盘分析:业务背景.问题描述.排查思路.经验教训. 一.业务背景 先简单描述一下业务背景吧.我们有个业务需要严格按顺序消费Topic消息,所以针对该topic设置了唯一的partition,以及唯一的副本.当同一个消费组的多个consumer启动时,只会有一个consumer订阅到该Topic,进行消费,保证同一个消费组内

故障排查:是什么 导致了服务器端口telnet失败?

telnet命令的主要作用是与目标端口进行TCP连接(即完成TCP三次握手). 当服务端启动后,但是telnet其监听的端口,却失败了.或者,当服务端运行了一段时间后,突然其监听的端口telnet不通了.当类似这样的telnet失败的情况出现时,都可以按照如下方面进行排查: 1.观察一下服务端进程的CPU和内存是否有异常. 比如,当CPU持续在100%时,就有可能导致来自客户端的TCP连接请求被丢弃或无暇处理. 2.端口监听器是否运行正常? 可以通过IRapidServerEngine的Adva

故障排查:是什么 导致了服务器端口telnet失败?(转)

telnet命令的主要作用是与目标端口进行TCP连接(即完成TCP三次握手).当服务端启动后,但是telnet其监听的端口,却失败了.或者,当服务端运行了一段时间后,突然其监听的端口telnet不通了.当类似这样的telnet失败的情况出现时,都可以按照如下方面进行排查: 1.观察一下服务端进程的CPU和内存是否有异常. 比如,当CPU持续在100%时,就有可能导致来自客户端的TCP连接请求被丢弃或无暇处理.  2.端口监听器是否运行正常? 可以通过IRapidServerEngine的Adva

Atitit.播放系统的选片服务器,包厢记时系统 的说明,教程,维护,故障排查手册p825

Atitit.播放系统的选片服务器,包厢记时系统 的说明,教程,维护,故障排查手册p825 1. 播放系统服务器方面的维护2 1.1. 默认情况下,已经在系统的启动目录下增加了俩个启动项目2 1.2. 后台服务.保持mysql数据库服务启动状态2 1.3. 影片图片与简介映射z盘需要有效可用2 1.4. 服务器如无必要无需关闭,保持一直开启状态...3 1.5. Loading时间的配置3 1.6. 其他3 1.6.1. 影片图片与简介缓存3 1.7. 包厢里面播放系统htpc的维护4 1.8.

SQL Server 2008性能故障排查(二)——CPU

原文:SQL Server 2008性能故障排查(二)--CPU 承接上一篇:SQL Server 2008性能故障排查(一)--概论 说明一下,CSDN的博客编辑非常不人性化,我在word里面都排好了版,贴上来就乱得不成样了.建议CSDN改进这部分.也请大家关注内容不要关注排版.同时在翻译的过程中本人也整理了一次思路,所以还似乎非常愿意翻译,虽然有点自娱自乐,但是分享给大家也是件好事 CPU 瓶颈: CPU瓶颈可能因为某个负载所需的硬件资源不足而引起.但是过多的CPU使用通常可以通过查询优化(

Linux运维常见故障排查和处理的33个技巧汇总

作为linux运维,多多少少会碰见这样那样的问题或故障,从中总结经验,查找问题,汇总并分析故障的原因,这是一个Linux运维工程师良好的习惯.每一次技术的突破,都经历着苦闷,伴随着快乐,可我们还是执着的继续努力,从中也积累了更多的经验,这就是实践给予我们的丰厚回报. 下面汇总了我做项目过程可能出现的故障及解决方法,看看是否与你有共鸣,并对你有帮助? 第一:常见问题解决集锦   1.shell脚本不执行    问题:某天研发某同事找我说帮他看看他写的shell脚本,死活不执行,报错.我看了下,脚本

跟我学-域名解析故障排查技巧

天苍苍,野茫茫,网站一瘫,唯有泪两行!!客户跳,老板叫,解析故障,心惊又肉跳!! 对企业网站来说,很怕出现网站打不开的情况,一旦发生,准会发现公司技术部呈现一片哀嚎景象.为了让运维的难兄难弟们做个精致的小白领,小编特别为你们总结了一套<域名解析故障排查技巧实操全网最全手册>,并分为“初阶版”“进阶版”,跟我学完保您在排查解析故障方面,脑回路神清晰,分分钟就能定位问题.为了助您减少客户不可用时间,并赢得老板信任,今天就来听听小编跟大家唠唠域名解析那点事儿. 因为DNS是互联网流量的入口,所以企业

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程(高俊峰)

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程 第一课 Linux运维经验分享与思路 1.一般把主机名,写到hosts下    127.0.0.1    hostname,因为很多应用要解析到本地.oracle没有这个解析可能启动不了. 2.注释掉UUID以及MAC地址,需要绑定网卡的时候,这个可能会有影响. 3.磁盘满了无法启动,  var下木有空间,无法创创建PID等文件,导致文件无法启动,按e   进入single  然后b  重启进入单用户模式. 4.ssh登陆系

Rsync 12种故障排查及思路

Rsync 故障排查整理 Rsync服务常见问题汇总讲解: ============================================================================================== 1 客户端的错误现象:No route to host rsync服务端开启的iptables防火墙 [[email protected] tmp]# rsync -avz /etc/hosts [email protected]::backup r