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 无法从根本上提升

 

来源：https://testerhome.com/articles/24707