国产数据库优化该做些什么

Posted 2021-08-13 白鳝的洞穴

今天一打开电脑，就看到屏幕的下方推送了一个关于朋友生日的提示。

90年代中后期，互联网时代初期，我一般使用MSN和网友聊天，当时国内上网的人还不多，所以当时的网友大多数是国外的Oracle DBA。现今MSN已经停服多年了，从Hotmail的联系人那也找不到这些信息，不知道哪个朋友知道如何找到这些被WINDOWS提示生日的人的详细信息，如果谁知道，不吝赐教。也许二十多年后，再找到这些老DBA去聊聊天，也是一件美事。

现在进入我们今天的主题，国产数据库优化，我们该/能做些什么？传统的商用数据库或者开源数据库优化总是有迹可循的，因为有大量的经验总结。而面对国产数据库的时候，我们似乎束手无策了，哪怕是基于开源代码改造的国产数据库，一旦其代码脱离开源社区独立发展之后，那么开源社区的经验就不一定用得上了。记得今年年初的时候，我们在测试OPENGAUSS的时候遇到了一些性能问题，到华为的官网上去咨询，官网上的人说这是开源产品的问题，把我们引导到了开源社区，在开源社区上发了一个咨询的帖子，很快就有机器人做了回答，然后呢，这个回答是唯一的回答了，几个月过去，没有一个真人去看过我们的问题。

虽然如此，国产数据库的优化也不是不能做的，记得早在2013年，当时我们接了一个优化项目，刚开始大家还觉得用户既然对系统的性能感受很差，那么优化是肯定能见效果的。到现场一看，傻眼了，数据库是达梦6，中间件是东方通，都是不大懂的东西。不过接了项目就必须硬着头皮干了。按照ORACLE的优化方案照猫画虎，也干了起来。最终这个项目的优化效果还不错，用户也挺认可，不过那时候的优化工作是比较粗粒度的，在不懂得数据库原理的基础上做优化，还是存在很大风险的。实际上那次对于数据库实例的调整看比如增加REDO组的数量，调整BUFFER等，效果并不明显，实际上起作用的还是添加索引，调整JDBC数据库连接池等工作。不管怎么样，那次优化总体上是成功的。也说明国产数据库的优化也是可以做的。下面根据我们这些年做国产数据库优化的经验，简单总结几条，给大家做个参考。

首先，肯定是SQL优化，国产数据库的CBO优化器往往做的不好，因此原来在ORACLE上可以运行的很好的SQL可能到了国产数据库上就跑步好，或者要开销更大的系统资源，因此任何一套运行于国产数据库上的系统肯定存在大量的SQL可以优化，而且如果不做SQL优化，这套系统往往无法很好的运行。针对索引、SQL语句、表分区、完善表分析策略、表数据历史归档等优化手段往往都是十分有效的。实在不行，就必须让开发商分拆大型SQL的业务逻辑，从而避免执行计划不好而导致性能问题了。

其次，操作系统优化，大部分国产数据库都严重依赖于操作系统，因此操作系统参数的调整，文件系统性能优化等，对于数据库性能的影响都很大。根据数据库的特性设置大页、调整VM参数、调整脏块刷新策略、选择合适的UNMA策略、放开ulimit限制、优化文件系统mount参数、选择适当的文件系统类型、合理分布IO到多个独立的文件系统、确保充足的存储容量等都对数据库的整体运行性能与稳定性有着极大的帮助。

再其次，DB CACHE的配置，不同的数据库的DB CACHE的设置方式是不同的，如果数据库使用DIRECTIO，不使用文件缓冲，那么将可用的内存尽可能多的设置为DB CACHE就好了。如果某个数据库不使用DIRECTIO,那么你还必须考虑有足够的内存用于文件缓冲，DB CACHE就不能设置的太大，一般设置为操作系统内存的20-30%就可以了。还有的操作系统可以选择是否使用DIRECTIO，那么就比较麻烦了，你必须针对你的应用系统去做测试，才能做出很好的选择。比如达梦数据库，默认是不使用DIRECTIO的，但是可以通过参数设置来调整策略。对于Benchmark测试类型的应用，达梦官方是不建议使用DIRECTIO的，不过对于其他类型的应用，达梦官方并没有做出建议。我们如果想要找到最佳的方式，那么就只能通过自己去试了。我想，也只有大量的用户经过大量的实践后，才能总结出哪些场景适合使用DIRETIO吧。国产数据库的这些优化因为缺乏官方引导，也缺乏第三方经验的总结，因此变得十分困难。我曾经有过针对某个国产数据库，经过一系列调优，把系统的Benchmark指标从18万降低到1万3的经历。后来实在找不出我调整的哪个参数出了问题，没办法找了一个原厂配置的参数文件覆盖回去，性能神奇的恢复了。

第四，仔细阅读官方文档，通过只言片语去了解一些系统原理性的东西，并据此设计优化方案。开卷有益，这一点对于国产数据库优化来说至关重要，因为官方文档试我们能够接触到的最全面，最准确的国产数据库的技术资料了。我最近阅读了多个国产数据库的管理员手册，通过手册中的一些细节，获得了大量数据库优化的经验。

有些时候，我们甚至无法找到任何可参考的资料，面对出现的性能问题，既无原理可以分析，也无MOS可以查找和咨询。如果我们面对的是一个开源数据库，还可以选择去阅读相关的源代码，对于已经闭源的国产数据库就十分头痛了。不过这种情况下，strace工具就是一个十分好的分析工具了。通过打印某些进程的trace来获得优化的灵感也就是没办法的办法了。

昨天在做PolarDB压测的时候发现了一个挺有意思的问题，今天把它分享出来。我在压测的时候发现好像总是遇到瓶颈，TPMC指标稳定在40万左右，CPU使用率在20%多点，就上不去了。于是我考虑是不是把polar_parllel_bgwriter_workers参数加大一点，这个参数缺省是5，我把它调整到最大-8。

参数调整后，TPMC指标略微提升了一点但是不明显。而且我发现，每秒事务数的指标波动很明显。

于是我只好用strace去trace了一下bgwriter和parallel bgwriter这两种进程。很快就有了重要的发现。

居然在Polar parallel bgwriter进程中有大量的futex的同步锁等待。在这个等待之前是对22号文件的pwrite64和fsync。我们通过lsof命令来看看22号文件是什么。

Bgwriter居然写的是wal文件！这有点颠覆了我的认知了。大家知道为了确保性能，wal文件是由专门的walwriter进程来写的，Oracle中是由lgwr来写的。为了确保最佳的性能，Oracle也一直是用一个单进程来写REDO，主要是为了避免串行化所带来的负面影响，有不稳定因素。在PolarDB中为什么要让bgwriter进程来写WAL呢（通过对bgwriter和polar parallel bgwriter的跟踪发现，这些负责写脏块的进程都会偶尔写一下WAL）？通过对PolarDB读写分离重演机制的研究我们已经了解到，为了确保只读实例重演日志的需要，某个PAGE被写盘的时候，要尽可能确保其REDO项已经存盘。不过多个后台进程同时写WAL会带来串行化的需求，因此需要写盘的进程数量越多，串行化的成本就越高。基于这个思路去考虑，我尝试把polar_parallel_bgwriter_workers参数设置为0。于是奇迹出现了，TPMC从42万一下子提升到52万。

每秒事务数的指标也变得更为平稳了。

数据库优化，不理解原理就去做调整，确实风险很大。这实际上也是10年前我写《DBA的思想天空》的初衷。