一、施压机器(压测平台本身 CPU 高,打不出压力)
现象:压力还没给到业务,压测机器先跑满,TPS 上不去
简单办法:
1、压测别开图形界面,关掉多余日志、多余校验;
2、脚本里尽量复用长连接,少频繁新建连接;
3、一台机器扛不住,就加多台机器分布式压;
4、减少脚本里复杂计算。
二、业务服务器 CPU 被压满(真正达到服务处理上限)
先看是哪种情况:
1、业务代码占用 CPU 高(us 高)
找到耗资源代码:循环、JSON 解析、加密、重复查库
办法:加缓存、优化代码、优化 SQL;优化不了就多部署实例分担压力。
2、系统内核 CPU 高(sy 高)
大多是大量短连接、线程太多,系统频繁切换任务
办法:开启长连接,合理设置线程数量,不要乱开大量线程。
3、软中断高(si 高,和网络挂钩)
大量小包请求,网卡不断产生中断抢占 CPU
办法:开启网卡多队列,尽量合并小请求。
4、单个 CPU 核心跑满,其他核心闲着
存在单线程瓶颈、全局锁,任务只能一个核心跑
办法:拆分锁,改成多线程并行处理。
简执行顺序
先确认:是压测机器卡,还是业务服务器卡
压测机器卡 → 优化脚本、分布式施压
业务服务器卡 → 抓热点代码优化;优化不动就扩容
留意:别把 “压测机器能力不足” 误以为是业务性能差
重点总结
施压机 CPU 满 = 压力发不出去,测试结果不准;
业务机 CPU 满 = 达到当前版本处理上限,优先优化代码,其次扩容。