MySQL SYS CPU高的案例分析（二）

标签：9.png   contex   wan   进程   次数   second   html   bubuko   src   

后面又做了补充测试，增加了每秒context switch的监控，以及SQL执行时各步骤消耗时间的监控。

【测试现象一】

启用1000个并发线程的压测程序，保持压测程序持续运行，保持innodb_spin_wait_delay默认值不变

在10:17:14秒将innodb_spin_wait_delay值从默认值6调整为18，看到sys从40%降到20%

TPS从1.7W增加到2W

context switch从82W降到78W

【测试现象二】

开启SQL执行时各步骤消耗时间的监控，重点关注stage/sql/update步骤的时间消耗(TIMER_WAIT的单位是picoseconds)，下面是截取了每个场景下执行接近平均时间的SQL过程采样。

1、下图是单句insert执行时情况，stage/sql/update时间约0.077豪秒

2、下图是innodb_spin_wait_delay=6时，TPS约在1.7W时insert执行时情况，stage/sql/update时间约32毫秒

3、下图是innodb_spin_wait_delay=18时，TPS约在2W时insert执行时情况，stage/sql/update时间约1.5毫秒

【测试结论】

1 、关于加大spin_wait_delay的理解，增大spin_wait_delay会让线程在进入os wait之前再多spin一段时间，增加时间会增加获取到rw-lock的概率，减少CPU空转的次数，当spin wait的循环次数在1-30之间获取到rw-lock时，则不会进入os wait，这种情况下减少了context switch的次数。从而减少了sys CPU的消耗，表现出来的现象是SQL执行时间变短，TPS处理能力上升。

2、innodb_spin_wait_delay的单位，是100MHZ的奔腾处理器处理1毫秒的时间，默认innodb_spin_wait_delay配置成6，表示最多在100MHZ的奔腾处理器上自旋6毫秒。

现在CPU是按照GHZ来计算的(测试是基于Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz 40核的CPU处理器)，默认值相对变的很短，建议可以将这个配置值适当调大。

3、MySQL高并发写入出现瓶颈，确实不像SQL Server的Latch等待类型那么明显。我们需要结合TPS、CPU、IO、运行进程等情况来综合定位。

MySQL SYS CPU高的案例分析（二）

标签：9.png   contex   wan   进程   次数   second   html   bubuko   src   

原文地址：https://www.cnblogs.com/lonelyxmas/p/9825433.html