学艺不精 - 记一次性能问题排查

问题的现象:

客户端登录平台服务器后经常掉线。

排查阶段1:

首先常规检查,磁盘容量没有问题、load average很低、cpu、mem使用率都不高、平台各服务配置、策略路由都反复检查过好几遍均没有问题。

由于客户端首先是通过nginx接入,所以下来查看nginx日志文件。此时发现nginx每天生成的日志文件大小将近有10G。

通过对日志进行分析得出非高峰时段对nginx中某个接口的每秒请求超过1200次。

对比使用平台的用户数(日均活跃用户400人左右),对该接口每秒1200次的请求显然是不正常的,但仍在nginx的承受范围内。

同一时段,观察到nginx所在服务器对后端服务器的转发经常超时,通过抓包发现转发包并没有能够发送(后端服务器也没有收到),怀疑nginx所在服务器连接资源可能存在问题。

使用ss -s命令查看发现,存在大量的timewait状态的socket连接,并且ports已经达到了系统设置的上限。

查阅相关资料,由于nginx使用短链接,因此在高频请求下会产生大量的timewait状态的socket连接、占用系统端口资源。

临时解决方法:

放大系统端口数量-如修改sysctl中net.ipv4.ip_local_port_range = 1024    65000

设置端口回收-修改sysctl中net.ipv4.tcp_tw_recycle = 1

但这只是治标不治本,时间一长端口仍然会被占满。

此后经过平台业务开发的修改业务代码,将对nginx请求数降低到了每秒100次以下,上述端口资源被占满的问题彻底解决。

排查阶段2:

然而就在上述问题解决后没多久我们就发现客户端掉线的问题依然存在,只是掉线频率下降了一些。

由于没有更好的排查手段,依然只能通过抓包,发现客户端到平台服务器有丢包现象。

ifconfig查看网卡信息发现RX packets中有大量的dropped包,

ethtool查看网卡信息Supported link modes:   100baseT/Full,即百兆网卡,因此怀疑是网卡性能不足。

由于该服务器是运行在kvm上的虚拟机,当时在配置虚拟机网卡时device model选择的默认Hypervisor default推测为百兆网卡,因此在虚拟机控制台中将网卡模型调整为e1000(千兆网卡)。

调整过后RX packets 不再出现dropped包

排查阶段3:

然后问题并没有得到缓解,掉线依旧。疑点是nginx所在服务器ping后端服务器丢包严重,但原因不明。

大家束手无策,只好请大拿出马。

大拿终究是大拿,不久就发现了问题:虽然load average的值很低,但是其中一个cpu的hi(硬中断)很高,接近满负荷。

通过查看/proc/interrupts,发现该cpu已被网卡中断拖垮,怀疑是虚拟机配置的网卡和cpu性能不足。

因此再次在虚拟机控制台中修改网卡模型为virtio(这个模型性能最好);调整cpu模型:copy host CPU configuration,调整pinning尽量使得与其他虚拟机不同时占用相同的物理机cpu。

解决结果:

通过上述调整,最终彻底解决了客户端掉线问题。

时间: 2024-10-31 13:46:44

学艺不精 - 记一次性能问题排查的相关文章

谨记一次问题排查经历

一个客户那儿: 1接收报文->2系统转码->3发送给处理程序->4处理程序调用数据库存储过程 现在系统数据库库内记录出现问题了:某个关键字段的值扩大了10倍:自某个时间4-19日开始发现该问题:上游厂商确定没有变动过接口. 经过:根据分析和经验,认定问题出现在2上,初步推断是上游接口发生变化而未告知(上游有前科).重新依据生产环境部署程序.重新测试.问题仍在.期间发现过和汇率可能有关系.当时没有程序源代码. 接下来..... 找上游争吵 ..... 最后:冷静下来,向公司原来负责该客户的

也记一次性能优化:LINQ to SQL中Contains方法的优化

距离上一篇博文更新已经两个月过去了.在此,先表一表这两个月干了些啥: 世界那么大,我也想去看看.四月份的时候,我入职了上海的一家电商公司,职位是.NET高级开发工程师.工作一个月,最大的感受是比以前小城市匆忙了许多,工作压力大了许多,开发方式更加的正规,不过各种流程也更加的繁杂细琐.在写代码的时候,一定要严谨细心,该验证参数合法性的时候验参,该抛异常的时候抛异常,该写日志的时候写日志,因为一个不小心而报黄页或者主流程无法顺利进行下去,是很没面子的事情.另外,我也更加关注代码的性能问题,开发环境和

记一个bug的排查过程---复盘

公众号做了新需求:菜单的click事件,支持多条客服消息. 上线后,只有一个功能不好使,是点击菜单,预期发一条文本类型的客服消息. 实际操作时,点这个菜单项后,什么也没有发生. elk上看日志,也没有什么报错.也不应该有报错,如果后端服务异常,公众号上会提示,“服务不可用”如果在后台打开 菜单管理 页面,什么也不做,再点个 保存 ,菜单 的功能就恢复正常了. ====================================================================

记一次性能测试:mysql占用磁盘IO过高 的解决过程

在一次性能测试时,发现mysql的cpu使用率不高,但是磁盘io很高, 一开始考虑是mysql的慢日志比较多,但是查看后发现慢日志并不多,而且只有一台mysql. 进入实例,查看sync_binlog变量 mysql> show variables like '%sync_binlog%' -> ; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | sync_binlog | 1 |

记一次性能优化经历

提到这次性能优化,好简单,仅仅是压缩了一下显示图片大小, 网页打开速度得到了显著的提升,抛砖引玉吧. 优化前 优化后: 在优化前,一次产品列表要显示12张图片,每张图片在600kb左右,也就是每打开一次当前页面需要传输7.2mb左右的图片文件,压缩后,每一张图片在12kb左右,每次传输200kb,由此可见,降低网络传输量,可以显著提升网页浏览速度,采用小图片,压缩css,压缩js,把js放到一个文件中,这些都是减少网络传输途径.

记一次性能优化实战经历@告别2016

过了今天就2017了,做点什么呢,写点年终总结.个人小目标.或者?!今天窗外阳光十分的好,又恰逢周末,算了,还是用2016底的一次SQL Server数据库性能调优经历来做了结,告别2016! 不废话,上菜! 内容摘要: 一.性能问题描述 二.监测分析 三.等待类型分析 四.优化方案 五.优化效果 一.性能问题描述 应用端反应系统查询缓慢,长时间出不来结果.SQLServer数据库服务器吞吐量不足,CPU资源不足,经常飙到100%....... 二.监测分析 收集性能数据采用二种方式:连续一段时

记一次性能测试实践

1.测试对象 这次测了一些http接口和几个网页. 2.测试策略 2.1 基准测试:单个调用各接口循环100次计算平均响应时间 2.2 性能测试:单个接口调用以50并发用户数为单位,逐步加压直到预估的实际负载300并发用户,观察测试指标变化 2.3 压力测试:单个接口调用以50并发用户数为单位,逐步加压直到错误率过高或服务器资源使用率过高,观察测试指标变化 2.4 负载测试:预估实际负载为300并发用户数,在此基础上持续测试5分钟左右,观察测试指标是否达标 2.5 稳定性测试:预估实际负载为30

记一次OOM排查解决

现场人员反馈tomcat假死,已不能访问,而且一直报如下异常: SEVERE:Memory usage is low, parachute is non existent, your system may start failing. java.lang.OutOfMemoryError: Java heap space 很显然堆内存溢出了,现场配置了2G的堆内存,用jmap命令dump heap失败,添加参数-F强制dump半天没有反应,只能带着-XX:+HeapDumpOnOutOfMemo

记一次性能调优

说到性能调优,给人的感觉往往都是修炼有成的专家干得事了,对于我们这些菜鸟还是想也不要想了,做好分内事,不出现纰漏就OK了.对于这种观点我表示严肃的否决!那想学习性能调优的童鞋应该从哪里下手呢?接下来就让我们来谈谈关于性能调优你所忽视的一些常识. 一.代码:前文讲过“华为Java编程军规,每季度代码验收标准”这个标准是衡量代码本身的缺陷,也是衡量一个研发人员本身的价值.代码是性能调优中的一粒分子,分子虽小但经过上亿次的分裂也会变成黑洞,所以代码本身的缺陷也是我们性能调优的主因之一. 1 军规一:[