mysql占比函数_接招：一次因PAUSE指令变化引发的MySQL性能危机

作者：春林，来源：美团技术团队

哈喽，各位新来的小伙伴们，大家好！由于公众号做了改版，为了保证公众号的资源能准时推送到你手里，大家记得将咱们的公众号 加星标置顶 ，在此真诚的表示感谢~

正文如下：

作者介绍：春林，2017年加入美团，主要负责MySQL运维开发和优化工作。

MySQL得益于其开源属性、成熟的商业运作、良好的社区运营以及功能的不断迭代与完善，已经成为互联网关系型数据库的标配。可以说，X86服务器、Linux作为基础设施，跟MySQL一起构建了互联网数据存储服务的基石，三者相辅相成。

本文将分享一个工作中的实践案例：因Intel PAUSE指令周期的迭代，引发了MySQL的性能瓶颈，美团MySQL DBA团队如何基于这三者来一步步进行分析、定位和优化。希望这些思路能对大家有所启发。

一、背景

在2017年，Intel发布了新一代的服务器平台Purley，并将Intel Xeon Scalable Processor(至强可扩展处理器)重新划分为：Platinum(铂金)、Gold(金)、Silver(银)、Broze(铜)等四个等级。产品定位和框架也变得更加清晰。

因美团线上海量数据交易和存储等后端服务依赖大量高性能服务器的支撑。随着线上部分Grantly平台E系列服务器生命周期的临近，以及产品本身的发展和迭代。2019年开始，RDS(关系型数据库服务)后端存储(MySQL)开始大量上线Purley平台的Skylake CPU服务器，其中包含Silver 4110等。

Silver 4110相比上一代E5-2620 V4，支持更高的内存频率、更多的内存通道、更大的L2 Cache、更快的总线传输速率等。Intel官方数据显示Silver 4110的性能比上一代E5-2620 V4提升了10%。

然而，随着线上Skylake服务器数量的增加，以及越来越多的业务接入。美团MySQL DBA团队发现部分MySQL实例性能与预期并不相符，有时甚至出现较大程度的下降。经过持续的性能问题分析，我们定位到Skylake服务器存在性能瓶颈：

• CPU负载相对较高。

• TPS等吞吐量下降。

接下来，我们将从Intel CPU、ut_delay函数、PAUSE指令三方面入手，进行剖析定位，并探索相关优化方案。

二、性能问题分析

1、Grantly与Purley CPU性能差异

首先，基于上述两代平台的CPU(Grantly和Purley)，通过基准测试，横向对比在不同OS下的性能表现。

通过基准测试数据，总结如下：

• 在oltp_write_only(只写)的场景下Purley 4110的性能下降较为明显。

• 同为Purley 4110，CentOS 7比CentOS 6 oltp_write_only(只写)性能有提升。

我们通过二维折线图，来展示性能之间的差异：

在上图中，同为Purley 4110，CentOS 7比CentOS 6性能有提升。具体提升原因，因不涉及本文重点内容，所以不在这里详细展开了。

New MCS-based Locking Mechanism Red Hat Enterprise Linux 7.1 introduces a new locking mechanism, MCS locks. This new locking mechanism significantly reduces spinlock overhead in large systems, which makes spinlocks generally more efficient in Red Hat Enterprise Linux 7.1.

红帽官网Release Notes显示，从内核3.10.0-229开始，引入了新的加锁机制，MCS锁。可以降低spinlock的开销，从而更高效地运行。普通spinlock在多CPU Core下，同时只能有一个CPU获取变量，并自旋，而缓存一致性协议为了保证数据的正确，会对所有CPU Cache Line状态、数据，同步、失效等操作，导致性能下降。

而MSC锁实现每个CPU都有自己的“spinlock”本地变量，只在本地自旋。避免Cache Line同步等，从而提升了相关性能。不过，社区对于spinlock的优化争议还是比较大的，后续又有大牛基于MSC实现了qspinlock，并在4.x的版本上patch了。具体实现可以参看：MCS locks and qspinlocks。

在大致了解CentOS 7性能的迭代后，接下来我们深入分析一下Skylake CPU 4110导致性能下降的缘由。

三、CPU性能跟踪

1、定位热点函数

具体定位4110性能瓶颈，分如下几步:

• 首先，通过perf top来跟踪一下Linux CPU性能开销。

• 然后，通过perf record记录函数CPU周期的消耗占比。

• 最后，通过火焰图来验证定位热点函数。

可以看到，其中占CPU消耗占比较大为：ut_delay函数。

我们继续深挖一下函数链调用关系：

# Children      Self  Command  Shared Object        Symbol                                                                                                                                                                            # ........  ........  .......  ...................  ..................................................................................................................................................................................#
    93.54%     0.00%  mysqld   libpthread-2.17.so   [.] start_thread
            |---start_thread
               |          
               |--77.07%--pfs_spawn_thread
               |          |          
               |           --77.05%--handle_connection
               |                     |          
               |                      --76.97%--do_command
               |                                |          
               |                                |--74.30%--dispatch_command
               |                                |          |          
               |                                |          |--71.16%--mysqld_stmt_execute
               |                                |          |          |          
               |                                |          |           --70.74%--Prepared_statement::execute_lo