速递！病入膏肓的系统优化应该注意一些什么

我们马上就需要做一些补救，在月底高峰期来临之前，补充做一些降低总体负载的工作，首先要让这个月底高峰平稳过渡过去，然后才能给我们争取到半个多月时间，做更多的优化工作。等系统平稳后，再进行全面的优化。

(资料图片仅供参考)

最近我正在参与一套问题十分严重的系统的性能优化工作，这套系统就像一个随时可能死去的危重病人。面对一个病入膏肓的病人，中医不会下猛药希望立马根治，名医会先用一些温和的药调理，等到适合用猛药的时候再用比较激进的药方。西医也不会立马对病人开膛破肚，而是要把严重的炎症、发烧等症状压制好了，再进行手术。那么我们面对一个十分脆弱、性能糟糕的系统做优化，是不是也应该注意一点什么呢？

我遇到过不少DBA朋友都觉得对于系统，只要是优化就一定是有效的，因此哪怕做的不对症，也没有关系，大不了就是没效果呗。而事实上不是这样，一个糟糕的优化工作可能带来的负面影响是十分巨大的。快十年前了，一个客户的系统应用升级后出现了性能问题。表现在REDO量剧增，同时数据库的性能也出现了较为严重的瓶颈。

从RAC的两个节点的TOP 5 EVENTS上可以看出行锁等待很严重，同时存在比较严重的row cache lock的问题，共享池经常报ORA-4031错误。当时的运维人员认为需要做一些调整来解决当前的问题。

运维人员根据判断调整了几个数据库参数，本以为能够立即解决问题，没想到调整后系统反而变得更不稳定了，动不动就因我ORA-4031而导致宕机。经过调整后，这套系统甚至连生成一个AWR报告都经常因为ORA-4031报错而失败。

随后我们介入了这个优化项目，在进入现场后我们并没有立即动手做优化工作，而是做了一次业务人员与开发厂商的现场调研，掌握了一些系统的基本情况。

没有直接通过AWR报告的信息就去动手是因为我们仔细分析了负载文件，发现每秒执行数才1569，虽然硬解析等指标都很高，但是如此低的并发执行数，15GB的共享池经常出现ORA-4031，绝对不是简单的共享池碎片可以解释的了。

这个案例在我以前写过的《一个共享池性能问题的优化分析》这篇文章里了，大家有兴趣可以去翻阅。我今天提出这件事是因为最近面临的这个系统优化工作有类似的情况。为什么在优化工作中经常会遇到这样的事情呢？

这是我多次说的系统中的排队效应。系统存在优化的地方，特别是因为系统资源不足等原因出现了严重性能问题的系统，都会在某些地方存在堵点。这些堵点是导致当前性能问题的关键点。随着某些堵点被打通，从用户会话到后端存储的整条链路的吞吐量会变得更大。此时如果出现一个可能导致更严重性能问题的资源的不足，那么拥塞情况不会变好，而会更糟糕。我疏通下水道的时候就遇到过这种情况，有时候采用了很多手段，疏通前虽然下水慢，但是还能慢慢漏水，而疏通后很可能就完全堵死，只能找专业疏通队来干了。

面对这样的系统，可能很多有经验的DBA都会看出来，DB CPU过高应该是急需解决的问题，如果不解决这个问题，很可能会引发更严重的问题。确实是的，这套系统在业务高峰期的操作系统R队列长度经常长时间超过600(128核的服务器)。

实际上这套系统在不同的时间段表现出来的问题还是有些不同的。IO负载也很高，两个节点高峰期的IOPS超过10万，RAC INTERCONNECT的网络吞吐量也很高，一小时平均值都在100M/秒，高峰值超过250M/秒。因此我们也可以看出GC方面的等待也很高。

开发商的专家提出IO负载过高，因此要尽快降低IO资源，找出了十来张缺索引的表加了一通索引，期望能把IO负载降下去。这种加索引是项目组的常规操作，发现哪条SQL慢了就试着加索引。我们觉得当前阶段加一些索引风险还可控，因此也没有太阻拦。不过加过索引之后，IO负载并没有预期的下降。

他们对此也很不理解，按照他们的想法，IO问题应该解决的差不多了才是。实际上通过加索引，打通了这个小堵点后，系统的总体负载更高了。

从AWR报告上看，每秒执行数从4000+提升为5500+了。从历史指标对比上看，也确实高了一些。更高的并发执行量导致了更大的IO负载。实际上这次优化后，并没有降低月底业务高峰期的系统负载，甚至让风险更大了一些。

于是我们马上就需要做一些补救，在月底高峰期来临之前，补充做一些降低总体负载的工作，首先要让这个月底高峰平稳过渡过去，然后才能给我们争取到半个多月时间，做更多的优化工作。等系统平稳后，再进行全面的优化。

标签：