后面又做了补充测试,增加了每秒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、运行进程等情况来综合定位。