第37问:自旋锁 旋着旋着人就糊涂了 - 技术分享 - 新闻资讯 - 爱可生

第37问:自旋锁 旋着旋着人就糊涂了

发布时间:2021-05-25 浏览次数:406

关键字:MySQL云数据库oracle分布式数据库rds MySQL

问题

追求 MySQL 的性能时,总听说要调整自旋锁的参数: innodb_spin_wait_delay 和 innodb_sync_spin_loops,是真的么?


实验

首先我们要知道自旋锁的优点:自旋锁要上锁时,如果需要等待其他线程释放锁,那么:

  • 在等待锁的过程中会先线程会先自旋一段时间

    • 自旋阶段,线程不会放弃 CPU
  • 自旋过后:

    • 如果可以获取锁了,那么响应会比较快(自旋没发生上下文切换)

    • 如果还需要等待锁,再用更高成本的方式进行锁等待

innodb_spin_wait_delay 参数决定了自旋阶段的长度。现在我们试着调整 innodb_spin_wait_delay 参数,来测试一下:

先宽油起一个数据库,此处忽略步骤

建个表,放点数据:image

配置好 performance_schema:image

检查一下相关参数:image

清理 performance_schema 的统计值:image

来点压力:image

查询一下锁等待成本最高的锁:

image

可以看到锁等待成本最高的是 lock_mutex,是保护 MySQL 锁系统的锁

下面我们来调整一下 innodb_spin_wait_delay,让自旋的时间变长:

image

重做一次压力(记得先清理统计数据),查看统计数据:image

可以看到 lock_mutex 的平均等待时间从 751267 增加到了 1399041。我们让自旋阶段增加了 10 倍,锁等待的时间也会随之增大。

目前的实验看上去自旋阶段越短越好,那么自旋阶段是不是就没有意义了?当然不会。

大家可以将 innodb_spin_wait_delay 设置为 1,再进行测试,随着自旋阶段的减少,锁等待的时间也会随之增大(大部分锁都使用了高成本的方式来进行等待)。

那么如何选择自旋的参数呢?我们建议“不出问题不瞎调”。

在之前的统计数据中,时间的单位是:cycle,根据以下换算表,锁的平均时间是 1399041 cycle,大概也就 0.5ms(1399041 / 2385353233 = 0.00058 s),占 SQL 的整体时间很低,可以不用瞎调。

image

一个著名的 CPU 问题

自旋阶段,MySQL 会调用 CPU 的 PAUSE 指令,既能占用了 CPU,同时 PAUSE 指令(比起其他占用 CPU 的指令)也比较节能。

不过既然占用了 CPU,那么就会体现在 CPU 的使用率上。

现在我们将 innodb_spin_wait_delay 再放大一点比较一下:image

可以看到 CPU 使用率会随着自旋阶段变长而升高

Intel 的 Skylake 系列 CPU,调大了 PAUSE 指令的周期时长。从 10 cycles 调大到 140 cycles(也许是因为让 PAUSE 周期变长更有利于节能)

类似于今天的实验,这个指令的调整相当于拉长了自旋阶段。

这就导致了在 Skylake 系列 CPU 下,MySQL 的锁表现和 CPU 占用率表现都有可能更糟糕。

(推荐文章:https://tech.meituan.com/2020/04/16/intel-pause-mysql.html)

小贴士

看到这里大家是不是开始焦虑了,要准备换 CPU 了?

其实不必焦虑,绝大部分情况下,大家不用追求极致的性能。比起榨取服务器的一点点极限性能,业务稍微调整一下 SQL 取得的收益会 大几个数量级。

俗话说:业务写得好,运维回家早。


关键字:MySQL云数据库oracle分布式数据库rds MySQL

相关推荐

产品试用 产品试用
400-820-6580 免费电话