CPU软中断实践一
最近在对一个MySQL项目进行性能测试 QPS在1.1W到1.5W之间波动，但通过tcprstat观察到，响应时间不是非常稳定，会从0.3ms波动到1.9ms
响应时间监控，avg代表的是平均响应时间，单位为微秒，这里可以看到，平均响应时间为0.3ms 到1.7ms之间波动
@淘宝褚霸 在帮忙分析的时候，给了三点建议 1.CPU 2.IO 3.内存 这里先从CPU使用优化来总结一下
1.首先定位系统的CPU占用是否正常，可以使用 命令 mpstat –P ALL 1
我们可以看到第四颗CPU的idle百分比明显比其他CPU要低好多。那这颗CPU到底在忙什么事情？ perf top 工具可以帮我们查看，这颗CPU上面跑的进程的百分比
2. sudo perf top –cpu=4 
输出的结果和oprofile相似，但perf top可以实时来做cpu采样，这点比oprofile要好使得多。
另外一个工具是 taskset ,例如 taskset -p 03 700 的意思是把pid为700的进程绑定到第四颗CPU上面
[...] 测试人：彭立勋,B2B TPS：峰值2800，谷值2300，均值2500 重要配置：（在测试3的基础上） innodb_aio_pending_ios_per_thread=512 alter tablespace `trade/xxx` set extent_size=5000000; # 预先扩展数据文件 测试人描述： 根据测试4的结果进行分析，需要解决的主要问题就是抖动，抖动可能是两个原因导致的，一个是Checkpoint机制不完善，一个是数据文件扩展。Checkpoint机制不完善这个暂时无法改进，只能先解决数据文件扩展上的问题，采用淘宝丁奇的方法，对MySQL增加预先扩展文件的功能，在测试前先将文件扩展至测试写满需要的大小，使测试过程中无需扩展文件。 实例测试中发现非常有效，抖动范围在2300～2800之间，可以接受。但是Buffer Pool一旦脏页写满，为了控制脏页量InnoDB就会加大刷新量，影响到TPS。实际上在脏页未满的时候，IOPS就没有用完，但是InnoDB计算刷新量并没有考虑操作系统反馈的影响信息，只是根据自己的redo产生量计算。 同时观察CPU还发现，2.6.18内核会将所有软中断发送到Core0上处理，这可能也是瓶颈之一。（当时忘记拷贝状态，这是后来确认内核问题看得，可以看这篇文章，一样的，CPU软中断实践） 03:05:17 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 03:05:18 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1014.00 03:05:18 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1000.00 [...]