Mysql的ut_delay问题分析

前阵子我发过一个关于闩锁与SPINLOCK的帖子，其中简单的提到了CPU的PAUSE指令对SPINLOCK的影响。当自旋锁无法获得SPINLOCK的时候，已经占用了CPU的线程没必要放弃CPU进入休眠，等待再次尝试获得SPINLOCK，因此会在该CPU上自旋。不过对于争用比较严重的系统，自旋多次后，有可能仍然无法获得SPINLOCK。因为自旋时该线程需要持有CPU的串行锁，因此，对于具有多个线程（比如至强芯片是双线程的）的CPU来说，这种长时间自旋而无法获得SPINLOCK的情况会导致另外一个CPU线程也被锁死，无法执行。为了解决这个问题，LINUX针对SPINLOCK的算法做了一些优化。

我们可以看到_raw_qspin_lock首先通过lock cmpxchg来获得spinlock，如果当前SPINLOCK无人持有，则直接获得SPINLOCK，就调用queued_spin_lock_slowpath来继续自旋。今天篇幅有限，我们不讨论详细的细节。直接看queued_spin_lock_slowpath的代码。

在这段代码中，就可以看到多出存在PAUSE指令的地方。通过PAUSE，该线程可以暂停几个时钟周期，让该CPU中的其他线程可以获得CPU的公共资源来执行其他任务。上回我也说过，美团团队的一篇论文中探讨了不同的X86 CPU因为PAUSE的时钟周期的不同对SPINLOCK性能会产生影响。发现这个问题的原因是他们的MYSQL数据库在更换了新的SKYLAKE服务器之后，QPS反而下降了15%。

正好今天我也在分析一个MYSQL数据库的问题，通过perf发现ut_delay的比例比较高。

我们来看一下ut_delay的汇编代码：

可以看到ut_delay是Mysql中轻量级锁、读写锁做自旋时，用于产生一个pause暂时让出CPU，避免SPINLOCK引擎严重的CPU性能问题的一个公共函数。如果spinlock相关参数设置的不合理，那么就会出现ut_delay引起性能问题的情况出现。搞清楚这个问题，那么我们就可以去检查一下innodb的spin相关参数了。

可以看出，这两个参数都是用的缺省值，一般情况下，也不要轻易去调整这个参数，因为调整的不合适，可能会导致更为严重的性能问题。我查了一下，网上也有一些关于优化ut_delay问题的文章，一般都是建议把delay调整为40，loops调整为100。实际上这是不够科学的，因为针对不同的CPU，调整是有讲究的。根据美团论文的描述，针对第一代SKYLAKE CPU，delay调整为3，Loops调整为20性能最佳。于是我直接尝试了一下这个调整：

从下面的图可以看出，调整后，ut_delay减少了20%左右，从系统上看，QPS也提升了13%左右。看样子这个参数调整策略是有效的。

接下来我们按照网上的建议，把delay调整为40，Loops调整为100，再来看看perf的信息。Ut_delay的占比更为严重了。

上面的例子证明了美团的论文关于spinlock与不同CPU 的pause命令持续的时钟周期的分析是完全正确的。我们进一步减少相关的设置，看看效果如何。这回我们把delay设置为2毫秒，loops设置为10。

可以看出，ut_delay占的比例明显降低了，不过native_queued_spin_lock_slowpath的等待比例明显增加了。从QPS上来看，比3/20的组合还是要略微第一点。

从这方面来看，spinlock的优化不是那么简单的事情，与服务器的配置，CPU型号以及应用的类型都有关系。因此调整这两个参数一定要慎重。

通过这个例子我又突然想起来前阵子遇到的一个达梦的性能问题。当时发现存在大量的pthread_spin_lock。SYS CPU的比例偏高，QPS怎么也上不去。

于是检查了一下数据库参数，发现SPIN_TIME设置为500。于是考虑是不是把SPIN_TIME加大能够提升QPS。

于是把SPIN_TIME加大为20000，发现调整参数后，数据库的并发处理能力提升超过了10%。再来看perf的情况。

是不是看上去舒服了很多。这说明在这种高并发的场景下，调整达梦数据库的spin_time参数，也是有效的。