健康系统的优化应该是问题导向的

白鳝的洞穴 2021-02-06

646

这是一个十分有争议的话题，肯定有人会说，既然是健康的系统，那么还优化个啥劲啊，不是瞎折腾吗。是的，对于大多数情况来说，健康的系统是不需要做优化的，因为有限的运维资源必须花在有效的地方才最有价值。中国人有句话，有病治病，无病防灾。防患于未然还是必要的，说不定哪一天，健康的系统就不健康了。还有一种情况是，虽然系统总体上来说是健康的，不过某些方面还是不尽如人意，比如说希望瞬间的高峰并发处理能力能够进一步提高。健康系统的优化是比较困难的，就像想让一个强壮的人更强壮肯定比把让一个瘦小枯干的人长点肌肉要难得多。

正是如此，为了节约不必要的浪费，对于健康的系统的优化，还是应该坚持问题导向。首先明确要解决的问题，然后再去做优化分析，为了优化而优化，缺乏明确的目标导向，会造成运维资源的巨大浪费。我们来看一个例子。

对于这样一个系统，如果我不明确一个优化目标，我们该怎么入手去做优化呢？似乎有点头痛，这个系统负载很高，每秒23M的REDO量，5300+的事务数，逻辑读似乎不算高，300多万每秒。看上去，OS负载也不会太高。

确实是的，这个96核的服务器，平均Load 30左右，CPU负载并不高。如果我们漫无目的的去做优化，该向哪个方向去做呢？建议用户减少提交的数量采用批量提交？这可能是一个正确而无用的建议。去优化IO？IO的性能已经够好了，如下图，大部分的数据库IO是在1毫秒以内完成的，大于8毫秒的数据库IO几乎没有。

为什么我们会遇到这样的困境呢？就是因为我们没有问题导向。优化是有成本的，对于相对健康的系统，漫无目的的优化会造成资源浪费。如果我告诉你，用户希望进一步提升高峰期的并发事务量，想从5000+/秒提高到6000+/秒，那么你是不是就没那么迷茫了呢？

如果有了这个目标，那么事情就简单多了，首先我们可以看看哪些因素导致了并发量上不去的问题。我们首先去看LOAD PROFILE中每个事务的情况

降低红框中的这些等待，肯定能降低每个事务的开销，从而提高每个事务的响应时间，从某些方面提高总体并发的能力。不过我们看得出，哪怕把这些全优化了，也还不够15%-20%提升这个目标。因此除此之外，我们还要再去分析如何提高并发处理能力的问题。比如闩锁的等待、共享池的等待、锁等待、BBW、GES/GCS等待等。同时提高一些关键缓冲池的命中率也有助于提高并发处理能力。

从上面的数据来看，LIBRARY HIT，LATCH HIT，SOFT PARSE的比例提升应该也是有效的。后续可以对这些做针对性的优化。

当然SQL优化也是行之有效的，对有问题的SQL也可以做一定的优化工作。

虽然让人缺乏一击必中的绝招，整个优化工作仍然需要十分细致的工作。但是总的来说，似乎优化还是有方向的，完成20%的目标虽然有一定的困难，需要较大的投入，但是完成10%以上还是很可能的。

数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

健康系统的优化应该是问题导向的

评论