从疏通下水道联想到的优化问题

在南京滞留了一个月后终于回到了深圳，虽然因为南京还没有解除出行管控，所以各地对低风险的南京还维持着较高的管控级别，到一些餐馆吃饭还需要出示48小时核酸，不过总算不需要隔离措施了。回到深圳要处理的就是家里的下水道堵塞的问题，因为装修时候改了线路，因此厨房的下水道总是存在堵塞的风险，因此以前每次回家都会做一些预防性的疏通工作。这回已经有一个多月没有疏通的下水道，已经出现了较为严重的堵塞问题了，现在洗菜盆使用的时候只能把水开小一些，以免积水过多。按照以前的方法烧一锅开水倒进去然后用温水冲刷，冲了半天也不见效果。于是只能倒了一瓶威猛疏通剂，一个小时后开始冲刷，刚开始的时候一切都很顺利，似乎下水也顺畅了很多。不过没过多久，突然发现整个下水道完全堵塞住了。根据经验，这是疏通开了第一个堵点后，所有的脏东西都在第二个堵塞点淤积，形成了一个更严重的堵点。于是只能等水流下去后再导入一瓶疏通剂，几个小时后再来疏通。这一回功夫没白费，整个下水道终于完全通畅了。

说了半天下水道疏通，并不是想让DBA们今后失业了增加一个谋生的手段，而是联想到了数据库优化。实际上数据库优化也存在类似的问题，这就是以前我多次说的系统优化中的排队效应。前年的时候我和大家分享了一个关于系统优化中的排队效应的案例。

在那个案例中，一个应用访问在很多地方都存在堵点，形成了排队，让后面的数据库、存储等并没有承受太大的压力，随着前面堵点的一个个排除，后面的基础设施都会遇到更大的压力，因此如果不对整个链路做全面的优化，那么这个系统经过优化之后可能会出现新的性能问题。

前两天我在做某个国产数据库的优化的时候，也遇到了类似的问题。我相通过一些参数调整来提升整个数据库的TPMC，刚开始从10多万到30多万的调整还是比较顺利的，根据数据库的原理区调整DB CACHE，各种工作区的大小，以及REDO/UNDO的一些配置，很快TPMC就上来了。不过到了30万TPMC再要往上调整，就比较难了。我调整了一系列参数，没想到TPMC值更低了。于是我开始做整体的分析，想了解到系统的问题在哪。通过一系列排查我发现在压测期间SYS的CPU特别高。

在压测进行的时候，SYS的CPU十分高。这种情况一般来说有几种可能，OS方面出现了很严重的争用，比如内存方面、IO方面的资源能力不足等。另外一方面就是数据库方面的闩锁冲突，SPIN LOCK自旋所带来的SYS CPU的大量消耗。这种情况，首先需要找出到底是哪方面出现了这么高的SYS CALL。这个时候，就需要使用Linux的系统调用分析工具perf了。perf top命令可以查看当前SYS CALL开销最大的调用（缺省安装不一定安装了perf工具，可以通过yum install perf来安装）。

果然SPIN LOCK是排在第一位的，再往下看，发现和BUFFER CACHE LRU连和BUFFER CACHE 搜索链相关的等待也排名靠前。于是我立马想到了热块冲突。于是采用HASH分区大法，把BENCHMARK中的几张大表都改成HASH分区表。调整之后，TPMC从30万提升到了40多万。不过SYS CPU依然很高。通过调整BUFFER CACHE等相关参数后的效果也不明显，甚至有时候把BUFFER CACHE加大后TPMC反而下降了。看样子HASH 分区依然无法解决热块的问题。仔细一想，在TPMC的场景中，虽然HASH 分区可以打散数据块，但是TPMC测试的数据访问比较均匀，打散数据块重组后的热块依然存在，因此HASH分区并不能解决TPMC中遇到的热块问题。

基于这个思路，另外一个解决热块的方法就涌现出了了，那就是减少每个数据块中存储数据的数量，ORACLE可以加大PCTFREE，正好这个数据库也有类似的参数，于是我把这个参数设置为60%。再加压，TPMC一下子就冲到了接近80万，最后稳定在75万左右。CPU也比较正常了，USR：56%，SYS:25%,还出现了接近20%的IDLE。看样子热块冲突就是这个下水道堵塞中的最大的一个堵点。

数据库优化也和下水道疏通一样，只有找到了最大的堵点，才能真正解决问题。在不同的应用场景下，这个最大的堵点并不固定，找到它也并不容易。因此在很多数据库优化工作中，优化团队并没有找到真正的堵点，只能通过SQL优化的方式减少系统负载，让系统能够较为平稳的运行。这一点就像我们家的下水道堵塞了一样，洗菜的时候把水开小一点，凑合先用着。实际上，在一些系统资源出现了瓶颈的场景下，有时候还不能仅仅依靠SQL优化，还需要把这个堵点找出来。

上面的图是我总结的一张一个集中式数据库在高负载情况下，比较容易出现瓶颈的点，不是很完整，大家可以参考。如果使用云平台或者云存储，那么HBA卡往后的部分需要重画，大家可以按照这个思路去做一个总结。当某个负载比较高的系统出现瓶颈的时候，我们不能仅仅从解决某个问题去考虑，而要从整体去考虑。看看整个链条上有没有其他的堵点。否则你解决了一个堵点问题，性能没有提升，甚至可能性能更糟糕了。这样你就会怀疑你的优化方向是不是错了。实际上你的调整并没有错，而是上游堵点解决后，下游更大的堵点产生了而已。就像我前面所举的例子，当热块冲突解决后，我再去调整DB CACHE,加大后明显会看到性能的提升，减少后也能看到下降，其规律是和我们理解的DB CACHE的作用是类似的了。而当热块冲突没有解决的时候，我们甚至会怀疑DB CACHE的原理是不是都不对了。