测试驿栈-由浅入深学性能 性能课堂-TPS 瓶颈精准定位
问题反馈
这是一个性能培训学员反馈的 TPS 问题
100 并发用户下的负载测试,TPS 最大升到 570 左右,然后跌到 400,并且长期保持。加线程也不能让 tps 再有所增加。
从监听到的服务器指标来看,cpu 利用率一直处于低迷的状态,大约只有 40% 左右。
问题定位
执行 vmstat 1 10
可以观察到,运行队列不是很长,iowait 不高,没有 swap 切换,但是上下文切换和中断似乎有点偏高
执行mpstat -P ALL 1
可以很明显的观察到软中断有点偏高,用户空间的 cpu 利用率大约是系统空间的两倍。
接下来 执行 watch -d cat /proc/interrupts
分析一下是什么导致的软中断过高
可以发现中断频率最高的两个网卡和 vmw 服务。有可能是网络出现了故障,但是 vmw 是什么暂时未知
执行 *netstat -n | awk '/tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' *,查看一下 timewait 有多少
4900 多 timewait,但是这似乎也不能说明什么问题。
接下来重头戏,需要拦截一下系统进程,看一下系统内部到底在做什么导致的切换和中断过高
执行 ** strace -o strace.log -tt -p 29779**
这条命令生成了一个进程日志,从日志里面可以看出一些问题
1:系统内部写日志的时候没有权限,出现了反复读写的死循环
2:tcp 连接超时了
现在问题大致明白了。因为系统反复写日志不成功,导致内核频繁的上下文切换;因为 tcp 连接故障导致的系统频繁中断
解决问题
1:调整了 tcp 的 keepalive 时间,从 1200 加到了 3000
2:增加了 tcp 缓冲和内存共享
3:日志问题开发暂时不想解决
结果
tcp 调整之后,最大 tps 增加到了 650 左右,但是还是会掉到 420。因为那个上下文切换过快导致了 cpu 无法正常工作,所以 tps 无法从根本上提升