文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

Intel PAUSE指令变化影响到MySQL的性能,该如何解决?

2024-12-24 17:38

关注

[[325430]]

1.背景

在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服务器存在性能瓶颈:

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

2.性能问题分析

2.1 Grantly与Purley CPU性能差异

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

通过基准测试数据,总结如下:

在oltp_write_only(只写)的场景下Purley 4110的性能下降较为明显。 2.同为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导致性能下降的缘由。

3.CPU性能跟踪

3.1 定位热点函数

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

 

 

 

 

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

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

 

  1. # Children      Self  Command  Shared Object        Symbol                                                                                                                                                                             
  2. # ........  ........  .......  ...................  .................................................................................................................................................................................. 
  3.     93.54%     0.00%  mysqld   libpthread-2.17.so   [.] start_thread 
  4.             | 
  5.             ---start_thread 
  6.                |           
  7.                |--77.07%--pfs_spawn_thread 
  8.                |          |           
  9.                |           --77.05%--handle_connection 
  10.                |                     |           
  11.                |                      --76.97%--do_command 
  12.                |                                |           
  13.                |                                |--74.30%--dispatch_command 
  14.                |                                |          |           
  15.                |                                |          |--71.16%--mysqld_stmt_execute 
  16.                |                                |          |          |           
  17.                |                                |          |           --70.74%--Prepared_statement::execute_loop 
  18.                |                                |          |                     |           
  19.                |                                |          |                     |--69.53%--Prepared_statement::execute 
  20.                |                                |          |                     |          |           
  21.                |                                |          |                     |          |--67.90%--mysql_execute_command 
  22.                |                                |          |                     |          |          |           
  23.                |                                |          |                     |          |          |--23.43%--trans_commit_stmt 
  24.                |                                |          |                     |          |          |          |           
  25.                |                                |          |                     |          |          |           --23.30%--ha_commit_trans 
  26.                |                                |          |                     |          |          |                     |           
  27.                |                                |          |                     |          |          |                     |--18.86%--MYSQL_BIN_LOG::commit 
  28.                |                                |          |                     |          |          |                     |          |           
  29.                |                                |          |                     |          |          |                     |           --18.18%--MYSQL_BIN_LOG::ordered_commit 
  30.                |                                |          |                     |          |          |                     |                     |           
  31.                |                                |          |                     |          |          |                     |                     |--8.02%--MYSQL_BIN_LOG::change_stage 
  32.                |                                |          |                     |          |          |                     |                     |          |           
  33.                |                                |          |                     |          |          |                     |                     |          |--2.35%--__lll_unlock_wake 
  34.                |                                |          |                     |          |          |                     |                     |          |          |           
  35.                |                                |          |                     |          |          |                     |                     |          |           --2.24%--system_call_fastpath 
  36.                |                                |          |                     |          |          |                     |                     |          |                     |           
  37.                |                                |          |                     |          |          |                     |                     |          |                      --2.24%--sys_futex 
  38.                |                                |          |                     |          |          |                     |                     |          |                                |           
  39.                |                                |          |                     |          |          |                     |                     |          |                                 --2.23%--do_futex 
  40.                |                                |          |                     |          |          |                     |                     |          |                                           |           
  41.                |                                |          |                     |          |          |                     |                     |          |                                            --2.14%--futex_wake 
  42.                |                                |          |                     |          |          |                     |                     |          |                                                      |           
  43.                |                                |          |                     |          |          |                     |                     |          |                                                       --1.38%--wake_up_q 
  44.                |                                |          |                     |          |          |                     |                     |          |                                                                 |           
  45.                |                                |          |                     |          |          |                     |                     |          |                                                                  --1.33%--try_to_wake_up 
  46.                ... 

 

将上述调用通过火焰图进行直观展示:

 

 

 

 

现在基本可以确定,所有的函数调用,最后大部分的消耗都在ut_delay上。

3.2 ut_delay和PAUSE之间的关联与性能影响

3.2.1 MySQL ut_delay实现

接下来,我们继续看一下MySQL源码中ut_delay函数的功能:

 

  1.  
  2. ulint 
  3. ut_delay( 
  4.  
  5.   ulint delay)   
  6.   ulint i, j; 
  7. ​ 
  8.   UT_LOW_PRIORITY_CPU(); 
  9. ​ 
  10.   j = 0; 
  11. ​ 
  12.   for (i = 0; i < delay * 50; i++) { 
  13.     j += i; 
  14.     UT_RELAX_CPU(); 
  15.   } 
  16. ​ 
  17.   UT_RESUME_PRIORITY_CPU(); 
  18. ​ 
  19.   return(j); 
  20. ... 
  21. ​ 
  22. #   define UT_RELAX_CPU() asm ("pause" ) 
  23. #   define UT_RELAX_CPU() __asm__ __volatile__ ("pause"

 

可以了解到,MySQL自旋会调用PAUSE指令,从而提升spin-wait loop的性能。

3.2.2 PAUSE指令周期的演变

我们可以看下Intel官网,也描述了在新平台架构PAUSE的改动:

Pause Latency in Skylake Microarchitecture

The PAUSE instruction is typically used with software threads executing on two logical processors located in the same processor core, waiting for a lock to be released. Such short wait loops tend to last between tens and a few hundreds of cycles, so performance-wise it is better to wait while occupying the CPU than yielding to the OS. When the wait loop is expected to last for thousands of cycles or more, it is preferable to yield to the operating system by calling an OS synchronization API function, such as WaitForSingleObject on Windows* OS or futex on Linux.

The latency of the PAUSE instruction in prior generation microarchitectures is about 10 cycles, whereas in Skylake microarchitecture it has been extended to as many as 140 cycles.

The increased latency (allowing more effective utilization of competitively-shared microarchitectural resources to the logical processor ready to make forward progress) has a small positive performance impact of 1-2% on highly threaded applications. It is expected to have negligible impact on less threaded applications if forward progress is not blocked executing a fixed number of looped PAUSE instructions. There’s also a small power benefit in 2-core and 4-core systems.

As the PAUSE latency has been increased significantly, workloads that are sensitive to PAUSE latency will suffer some performance loss.

衡量程序执行性能的简化公式:

ExecutionTime(T)=InstructionCount∗TimePerCycle∗CPI

即:程序执行时间 = 程序总指令数 x 每CPU时钟周期时间 x 每指令执行所需平均时钟周期数。

MySQL内部自旋,就是通过固定次数的PAUSE循环实现。可知,PAUSE指令周期的增加,那么执行自旋的时间也会增加,即程序执行的时间也会相对增加,对系统整体的吞吐量就会有影响。

显然,Intel文档已说明不同平台、不同架构CPU PAUSE定义的周期是不一样的。

下面,我们通过一个测试用例来大致验证、对比一下新老架构CPU执行PAUSE的cycles:

 

  1.  #include  
  2. #define TIMES 5 
  3. ​ 
  4. static inline unsigned long long rdtsc(void) 
  5.     unsigned long low, high; 
  6.     asm volatile("rdtsc" : "=a" (low), "=d" (high) ); 
  7.     return ((low) | (high) << 32); 
  8. ​ 
  9. void pause_test() 
  10.     int i = 0; 
  11.     for (i = 0; i < TIMES; i++) { 
  12.         asm( 
  13.                 "pause\n"
  14.                 "pause\n"
  15.                 "pause\n"
  16.                 "pause\n"
  17.                 "pause\n"
  18.                 "pause\n"
  19.                 "pause\n"
  20.                 "pause\n"
  21.                 "pause\n"
  22.                 "pause\n"
  23.                 "pause\n"
  24.                 "pause\n"
  25.                 "pause\n"
  26.                 "pause\n"
  27.                 "pause\n"
  28.                 "pause\n"
  29.                 "pause\n"
  30.                 "pause\n"
  31.                 "pause\n"
  32.                 "pause\n" 
  33.                 :: 
  34.                 :); 
  35.     } 
  36. ​ 
  37. unsigned long pause_cycle() 
  38.     unsigned long start, finish, elapsed; 
  39.     start = rdtsc(); 
  40.     pause_test(); 
  41.     finish = rdtsc(); 
  42.     elapsed = finish - start; 
  43.     printf("Pause的cycles约为:%ld\n", elapsed / 100); 
  44.     return 0; 
  45. ​ 
  46. int main() 
  47.     pause_cycle(); 
  48.     return 0; 

 

其运行结果统计如下:

 

3.2.3 Intel 提升PAUSE猜想

Intel提高PAUSE指令周期的原因,推测可能是减少自旋锁冲突的概率,以及降低功耗;但反而导致PAUSE执行时间变长,降低了整体的吞吐量。

The increased latency (allowing more effective utilization of competitively-shared microarchitectural resources to the logical processor read to make forward progress) has a small positive performance impact of 1-2% on highly threaded applications. It is expected to have negligible impact on less threaded applications if forward progress is not blocked executing a fixed number of looped PAUSE instructions.

3 PAUSE导致写瓶颈分析

接下来,我们深入分析一下PAUSE指令导致MySQL写瓶颈的原因。

首先,通过MySQL 内部统计信息,查看一下InnoDB信号量监控数据:

  1. SEMAPHORES 
  2. ---------- 
  3. OS WAIT ARRAY INFO: reservation count 153720 
  4. --Thread 139868617205504 has waited at row0row.cc line 1075 for 0.00 seconds the semaphore: 
  5. X-lock on RW-latch at 0x7f4298084250 created in file buf0buf.cc line 1425 
  6. a writer (thread id 139869284108032) has reserved it in mode  SX 
  7. number of readers 0, waiters flag 1, lock_word: 10000000 
  8. Last time read locked in file not yet reserved line 0 
  9. Last time write locked in file /mnt/workspace/percona-server-5.7-redhat-binary-rocks-new/label_exp/min-centos-7-x64/test/rpmbuild/BUILD/percona-server-5.7.26-29/percona-server-5.7.26-29/storage/innobase/buf/buf0flu.cc line 1216 
  10. OS WAIT ARRAY INFO: signal count 441329 
  11. RW-shared spins 0, rounds 1498677, OS waits 111991 
  12. RW-excl spins 0, rounds 717200, OS waits 9012 
  13. RW-sx spins 47596, rounds 366136, OS waits 4100 
  14. Spin rounds per wait: 1498677.00 RW-shared, 717200.00 RW-excl, 7.69 RW-sx 

可见写操作并阻塞在:storage/innobase/buf/buf0flu.cc第1216行调用上。

跟踪一下发生等待的源码:buf0flu.cc line 1216:

  1. if (flush_type == BUF_FLUSH_LIST 
  2.         && is_uncompressed 
  3.         && !rw_lock_sx_lock_nowait(rw_lock, BUF_IO_WRITE)) {    // 加锁前,判断锁冲突 
  4.          
  5.         if (!fsp_is_system_temporary(bpage->id.space())) { 
  6.          
  7.         buf_dblwr_flush_buffered_writes( 
  8.           buf_parallel_dblwr_partition(bpage, 
  9.                 flush_type)); 
  10.       } else { 
  11.         buf_dblwr_sync_datafiles(); 
  12.       } 
  13.       rw_lock_sx_lock_gen(rw_lock, BUF_IO_WRITE);        //  加sx锁 
  14.     } 
  15. ...  
  16.  #define rw_lock_sx_lock_nowait(M, P)       \ 
  17.   rw_lock_sx_lock_low((M), (P), __FILE__, __LINE__) 
  18. ... 
  19. ​ 
  20. rw_lock_sx_lock_func(                                       // 加sx锁函数             
  21.  
  22.   rw_lock_t*  lock,  
  23.   ulint   pass,  
  24.   const char* file_name, 
  25.   ulint   line)  
  26. ​ 
  27.   ulint   i = 0; 
  28.   sync_array_t* sync_arr; 
  29.   ulint   spin_count = 0; 
  30.   uint64_t  count_os_wait = 0; 
  31.   ulint   spin_wait_count = 0; 
  32. ​ 
  33.   ut_ad(rw_lock_validate(lock)); 
  34.   ut_ad(!rw_lock_own(lock, RW_LOCK_S)); 
  35. ​ 
  36. lock_loop: 
  37. ​ 
  38.   if (rw_lock_sx_lock_low(lock, pass, file_name, line)) { 
  39. ​ 
  40.     if (count_os_wait > 0) { 
  41.       lock->count_os_wait += 
  42.         static_cast(count_os_wait); 
  43.       rw_lock_stats.rw_sx_os_wait_count.add(count_os_wait); 
  44.     } 
  45. ​ 
  46.     rw_lock_stats.rw_sx_spin_round_count.add(spin_count); 
  47.     rw_lock_stats.rw_sx_spin_wait_count.add(spin_wait_count); 
  48. ​ 
  49.      
  50.     return
  51. ​ 
  52.   } else { 
  53. ​ 
  54.     ++spin_wait_count; 
  55. ​ 
  56.      
  57.     os_rmb; 
  58.     while (i < srv_n_spin_wait_rounds 
  59.            && lock->lock_word <= X_LOCK_HALF_DECR) { 
  60. ​ 
  61.       if (srv_spin_wait_delay) { 
  62.         ut_delay(ut_rnd_interval( 
  63.             0, srv_spin_wait_delay));                         // 加锁失败,调用ut_delay 
  64.       } 
  65. ​ 
  66.       i++; 
  67.     }                              
  68. ​ 
  69.     spin_count += i; 
  70. ​ 
  71.     if (i >= srv_n_spin_wait_rounds) { 
  72. ​ 
  73.       os_thread_yield(); 
  74. ​ 
  75.     } else { 
  76. ​ 
  77.       goto lock_loop; 
  78.     } 
  79. ... 
  80. ulong srv_n_spin_wait_rounds  = 30; 
  81. ulong srv_spin_wait_delay = 6; 

上述源码可知,MySQL锁等待是通过调用ut_delay做空循环实现的。

InnoDB层有三种锁:S(共享锁)、X(排他锁)和SX(共享排他锁)。 SX与SX、X是互斥锁。加SX不会影响读,只会阻塞写。所以在大量写入操作时,会造成大量的锁等待,即大量的PAUSE指令。

分析到这里,我们总结一下影响吞吐量的两个因素:

接下来,我们就从这两方面入手,评估优化空间以及效果。

4. 针对PAUSE指令和spin参数优化与探索

4.1 MySQL spin参数优化

4.1.1 MySQL 5.7 spin参数优化

我们可以基于现有MySQL版本、硬件等方面,来寻找优化点。

MySQL针对spin控制这块有个参数可以调整,根据参数特点进行相关优化:

innodb_spin_wait_delay

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

innodb_sync_spin_loops

当 innodb 线程获取 mutex 资源而得不到满足时,会最多进行 innodb_sync_spin_loops次尝试获取mutex资源。

其中innodb_spin_wait_delay参数对PAUSE运行时长是有影响的。针对此参数,我们进行调优测试。

 

 

 

 

同样,针对上述参数优化,我们通过基准测试来对比性能和效果:

 

可以总结为:

4.2 MySQL8.0 spin新特性移植

4.2.1 spin_wait_pause_multiplier移植

针对Skylake CPU,PAUSE造成的吞吐量下降,我们对MySQL 5.7 spin控制参数innodb_spin_wait_delay的调优并未取得明显效果。

于是,我们将目光投向了MySQL 8.0的新特性:MySQL 8.0 针对PAUSE,源码中新增了spin_wait_pause_multiplier参数,来替换之前写死的循环次数。

4.2.2 spin_wait_pause_multiplier实现

MySQL 8.0源码中,之前循环50次的逻辑修改成了可以调整循环次数的参数:spin_wait_pause_multiplier。

  1. ulint ut_delay(ulint delay) { 
  2.   ulint i, j; 
  3.    
  4.   const ulint iterations = delay * ut::spin_wait_pause_multiplier; 
  5.   UT_LOW_PRIORITY_CPU(); 
  6. ​ 
  7.   j = 0; 
  8. ​ 
  9.   for (i = 0; i < iterations; i++) { 
  10.     j += i; 
  11.     UT_RELAX_CPU(); 
  12.   } 
  13. ​ 
  14.   UT_RESUME_PRIORITY_CPU(); 
  15. ​ 
  16.   return (j); 
  17. ... 
  18. namespace ut { 
  19. ulong spin_wait_pause_multiplier = 50; 

4.2.3 移植spin_wait_pause_multiplier patch优化

既然MySQL 8.0参数spin_wait_pause_multiplier可以控制PAUSE执行的时长,那么就可以减少该值,从而降低整体PAUSE影响。

了解MySQL 8.0相关代码后,我们将该patch移植到线上的稳定版本:

  1. MySQ >select version(); 
  2. +------------------+ 
  3. | version()        | 
  4. +------------------+ 
  5. | 5.7.26-29-mt-log | 
  6. +------------------+ 
  7. 1 row in set (0.00 sec) 
  8. ​ 
  9. MySQL>show global variables like '%spin%';   
  10. +-----------------------------------+-------+ 
  11. | Variable_name                     | Value | 
  12. +-----------------------------------+-------+ 
  13. | innodb_spin_wait_delay            | 6     | 
  14. | innodb_spin_wait_pause_multiplier | 5     | 
  15. | innodb_sync_spin_loops            | 30    | 
  16. +-----------------------------------+-------+ 
  17. rows in set (0.00 sec) 

由上述可知,Silver 4110的PAUSE cycles是E5-2620 v4的14倍左右。基于此,将innodb_spin_wait_pause_multiplier值调整为默认值的1/14,取稍大值:5。即将该参数由原默认的50调整为5。

最后,还是通过二维折线图来对比该patch调优后的基准测试数据:

 

4.3 PAUSE指令周期优化

上述章节中,我们测出Cascadelake CPU PAUSE周期下降了。在跟Intel技术专家确认后得知:从Purley的第二代产品Cascadelake开始,Intel将PAUSE的指令周期降低到了44。(估计Intel也发现了第一代增加PAUSE周期后的性能瓶颈问题。)

我们针对第二代CPU产品继续做基准测试,来看一下性能表现:

 

接着用perf diff来对比一下4110和4210在ut_delay上的开销:

 

5. 总结

最后针对本篇内容,我们可以做个简单的总结:

Intel在新平台CPU产品调大了PAUSE指令周期,在高并发spinlock竞争激烈场景下,可能会造成程序性能较大损耗(特别是执行固定PAUSE次数的程序)。 针对Skylake架构CPU(比如:4110等)PAUSE指令周期较长引起性能问题的优化方法如下:

将MySQL 8.0 innodb_spin_wait_pause_multiplier patch移植到线上稳定版本(或升级到MySQL 8.0),通过降低PAUSE执行时长,来提升吞吐量。 如果是OS为CentOS 6,可以升级到CentOS 7,CentOS 7本身spinlock优化,对MySQL性能也有一定提升。 最简单、直接的方法可以替换为Cascadelake架构CPU。

针对Cascadelake架构CPU,由于Intel本身在PAUSE周期已经优化,性能上已经做了修复。当然也可以采用上述优化方案,让性能提升一个台阶。

6. 作者简介

春林,2017年加入美团,主要负责MySQL运维开发和优化工作。

 

 

来源:51CTO专栏内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯