注意了这个远古Bug,让你的MySQ

破产码农

IT圈最会讲故事的网红·南山彭于晏前面的文章已经展示了MySQL8.0的能力,96逻辑CPU下能跑出万的QPS。这时MySQL实例占用约58个逻辑核,约2.4WQPS/Core。IMG群的同学在做类似测试时,发现他的MySQL8.0却始终只能跑在不到50万QPS。通过姜老师的复盘,最终定位了问题,性能从40万提升为了万QPS。今天就来带给大家这次错综复杂的性能调优之旅。

1

版本选择

这次测试的版本是最新发布的MySQL8.0.24版本。直接使用的是编译好的LinuxGeneric通用版本:mysql-8.0.24-linux-glibc2.12-x86_64.tar.xz很多同学“迷信”从源码自己手工编译MySQL,从而获得性能的提升。其实手工编译完全没有必要,是错误的一种执念。试想下Oracle、MicrosoftSQLServer是不是都是给的二进制安装包?难道他们的性能在不同服务器上会有很大的差别么?你要明白,最终都是将代码逻辑编译成最底层的CPU执行命令,所以不会有本质的差别。

2

都是他惹的祸

接下来,我们进入到测试流程。这台服务器的硬件与之前的完全一样,操作系统安装的是CentOS7,内核版本3.10。这时通过我们的测试程序my_test进行主键的查询测试,会发现QPS被限制在了42W左右的QPS。而之前我们的测试一直是可以达到万的QPS。这时通过命令TOP观察CPU负载,会发现CPU使用率为62个逻辑核,比之前的还要高。但是,QPS反而大幅地下降。若仔细观察,会发现CPU使用率中,sys的使用率及其高,竟然达到了52.3%!!!有了这个线索之后,再要定位问题就非常简单了。再次祭出命令perf。通过perftop-G-p`pidofmysqld`定位出在测试过程中MySQL消耗最多CPU的函数是哪个。最终我们定位到了如下这个函数:可以发现发现这里MySQL调用了函数ppoll,占用了73.68%的CPU使用率。但我记得之前MySQLviosocket网络模块用的是poll,接着去MySQLworklog翻看官方工作日志。然而,并没有找到任何相关信息:接着,在github上搜索提交日志。这次终于找到了对应的代码修改信息。看来是Facebook提交的修复补丁:看了下,当前MySQL5.7并没有合并这个修复!!!接着大致扫了下源码,MySQL8.0用ppoll替换poll,用于安全捕获某些信号,这是常见的逻辑。所以,我并不认为MySQL8.0的修复存在太大问题。要再排查问题,就需要查看Linux内核了。这时我在Github上Linux的源码库中搜索:_raw_spin_lock_irqhighcpu这时终于定位到了问题的原因:原来这是操作系统的内核Bug!!!即:在多核CPU,高负载的数据库业务场景情况下,系统函数sigprocmask的自旋锁竞争会占用大量CPU时间。这个Bug在4.10版本就被修复,但我们的操作系统还停留在3.10版本。所以,要解决这个问题,要么根据Linux源码中的对signal.c进行内核修复并重新编译,或直接将操作系统升级到不低于4.10的版本。当然,也可以直接修改MySQL源码,牺牲ppoll的安全信号等待特性,退化为之前5.7的方式。修改MySQL8.0的源码violite.h:这样的话,仅在内核4.10版本及以上时,才会使用ppoll。编译后再进行测试,这时MySQL性能就能恢复到先前的百万QPS水准了:

4

看视频,更直接

视频编辑超级累,看完记得点赞哦!!!

3

总结

这个操作系统Bug5年前就已修复,但其极大影响了MySQL8.0的性能。然而,该Bug对MySQL5.7版本又毫无影响。可以说,藏得非常深。也是第一次真正遇到操作系统系统内核Bug直接影响数据库性能。因此,姜老师强烈建议:若你使用/升级MySQL8.0版本,务必确认自己的操作系统内核版本已经升级到4.10版本。否则,你的MySQL8.0体验可能是非常糟糕的。甚至可能让你痛不欲生~~~~看完这篇文章,你还有什么疑问呢?欢迎留言讨论哦~~~

直播预告

每周五、六,不定期直播,分享技术干货IMG群是码农的交流社区,IMG


转载请注明:http://www.aierlanlan.com/rzfs/789.html

  • 上一篇文章:
  •   
  • 下一篇文章: 没有了