我们一起用炒菜的道理来聊聊优化这项工作

• 2023-05-06 19:27:50 来源：清一色财经

针对这个Load Profile我们可以看出系统中存在很多高负载的点，每秒redo超过9MB，逻辑读632万+，物理读高达6.4万+/秒，一小时内的读写IOPS高达1.8万+，读IO吞吐量500MB+/秒，写IO吞吐量15MB/秒，每秒事务数100+，每秒执行数接近5000。针对这个负载文件，我们能给它找出食材配料表吗？

​优化这个话题是很多朋友感兴趣的，今天就再聊聊。很多人说给系统做优化就像医生治病，用药的君臣佐辅，下药的顺序都不能差了。我不懂中医之术，因此不好类比。不过我懂炒菜，就用炒菜的道理来聊聊优化这项工作吧。

要想让一道菜好吃，炒菜的主料配料选择与配比十分关键，只有主料一味未免单调，而选择比较抢戏的配料也不合适，会把主料的味道给冲了，让菜的味道变得比较怪异。合适的主配料搭配和配比是一道菜好吃不好吃的基础。

(资料图片仅供参考)

针对这个Load Profile我们可以看出系统中存在很多高负载的点，每秒redo超过9MB，逻辑读632万+，物理读高达6.4万+/秒，一小时内的读写IOPS高达1.8万+，读IO吞吐量500MB+/秒，写IO吞吐量15MB/秒，每秒事务数100+，每秒执行数接近5000。针对这个负载文件，我们能给它找出食材配料表吗？

也许有些朋友还比较谨慎，还需要继续看看等待事件和命中率的情况再下结论。从命中率上好像也看不出啥来，都是较高负载的系统应该有的命中率情况。唯一低点的是library Cache的命中率和软解析的比例。不过从解析占用的CPU资源上看，问题似乎也不算太大。

从等待事件上看，好像除了DB CPU外，都是gc方面的问题，单块读等待只占3.4%，而且平均延时只有1毫秒，说明存储性能不错。确实，本系统的主要数据都在闪存盘上。

从等待事件的分类统计上看，DB CPU占了近一半，cluster排第二位，占了26.9%。似乎解决掉这两个问题，系统的主要问题就都解决了。不过到这里我们还是无法做出很好的判断，必须继续分析。

这时候我们需要继续查看CPU的情况，因为从主要事件上看，CPU占比较大。从这个报告上看，LOAD居然高达500+，这对于128核，256线程的7、8年前采购的服务器来说，有点高了。

从OSW的数据上，我们也验证了CPU负载很高的问题。这套系统是问题十分严重的，因此现象表现其实是十分明显的，很容易找到我们需要的食材。CPU使用率过高、IO负载过高、REDO量过大、集群等待比较严重、共享池存在一定问题。这些都是目前系统存在问题的关键，也就是我们要享用的食材。

下一步就是怎么烹调这道菜了，煎炒烹炸，蒸煮煲汤，哪种方式更适合这些食材呢？这就是我们要制定的优化策略了。从这个系统上来看，有经验的DBA一定会选择先降低CPU的使用率，因为如此大的IO量，后端存储还撑得住，没有性能明显下降的趋势，在CPU与IO的选择中，首先会选择降CPU为主的做法。一旦确定了CPU优先的测了，那么在第一阶段的优化中，REDO的问题也不需要过多的考虑了，虽然平均每秒有9MB+的REDO量，以经验来看，全闪的SAN存储是没有任何问题的。

选定了烹饪方法之后，就要考虑烹制的细节了。先炝锅还是先爆锅，用荤油还是素油，加葱姜还是大蒜？这种选择奠定了采的基本味道，因此不得不重视。因为这套系统的优化需求十分紧急，因此找出一些逻辑读较高，CPU使用量较高的SQL，看看能不能通过添加索引，纠正执行计划等方法把CPU降一降。给后续的全面优化争取出一定的时间。

这个系统中的RAC GC的问题也很严重，要想分析如何优化GC，首先我们需要分析RAC的相关指标。

从RAC的相关指标上看，除了流量大一些以外，其他指标都正常，不算太差，说明GC问题不是系统性的，而仅仅是部分SQL不优化引发的，这种问题解决起来比较容易。在消息上，Ksxp队列上的延时比较大，indirect sent的比例偏高了一点。这些都是和流量较大有关的。因此降低RAC INTERCONNECT的流量应该是解决这个问题的比较稳妥的方法。虽然说优化CPU使用率高的SQL有助于降低RAC流量。不过我们如果能够针对性的解决问题，才会有更为明显的效果。

这些TOP SEGMENT相关的SQL语句是我们本次优化的重点，在这里我们发现了一张消息表。有200GB+，其中的数据可以删除清理。如果能够完成这个操作，可以大大降低RAC通讯流量。

经过这样一个个的分析，我们就基本上能够确定第一阶段的工作方案了。通过第一阶段，首先解决目前最为紧迫的问题，让系统恢复可用。然后给我们留出足够多的时间来做精细化的全面优化。通过全面优化，让系统焕然一新。​

标签：