优化这个话题是很多朋友感兴趣的,今天就再聊聊。很多人说给系统做优化就像医生治病,用药的君臣佐辅,下药的顺序都不能差了。我不懂中医之术,因此不好类比。不过我懂炒菜,就用炒菜的道理来聊聊优化这项工作吧。
要想让一道菜好吃,炒菜的主料配料选择与配比十分关键,只有主料一味未免单调,而选择比较抢戏的配料也不合适,会把主料的味道给冲了,让菜的味道变得比较怪异。合适的主配料搭配和配比是一道菜好吃不好吃的基础。
针对这个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通讯流量。
经过这样一个个的分析,我们就基本上能够确定第一阶段的工作方案了。通过第一阶段,首先解决目前最为紧迫的问题,让系统恢复可用。然后给我们留出足够多的时间来做精细化的全面优化。通过全面优化,让系统焕然一新。