降低cpu使用率（一种CPU使用率高的常见处置方法）

昨天晚上在南宁和白鳝X的老朋友小聚一场。大多数朋友是2003-2008年在网上聚在“白鳝的X”QQX的，不过很多那时候的翩翩少年的鬓角已经看到丝丝白发了，老白也到了知天命的年龄，时间真的过的很快。先上一张昨晚的合影，喝了点酒，大家的表情都放的挺开。
看完照片我们言归正传。这是一个十年前的案例。客户发现系统较慢，CPU开销很高，平均处于70%以上。于是在QQ上让我帮助诊断。我首先要他发来一份AWR报告。
从负载上看，不是很高，逻辑读的数量51.7万，不过十多年前的小型机比起现在的X86服务器来性能都差了一大截，这个系统当时也算是负载比较高的了。
可能有很多朋友看到LIBRARY CACHE命中率才不到70%就会把目光关注在这上面了，客户的DBA也怀疑LIBRARY CACHE是不是问题的根源。实际上，我们看non-parse CPU的比例为98.4%，就可以放心了，LIBRARY CACHE 大概率不是导致CPU使用率过高的原因。
这是一个10.2.0.4的库，所以CPU使用情况需要我们自己算一算：
这个系统有16个CPU核，通过计算可以算出大概CPU IDLE的比例是20%左右，一个2小时的SNAP里，这么高的CPU使用率确实算是很高了。估计经常会有瞬间CPU达到100%了。当然CPU使用率高并不一定意味着存在瓶颈，不过客户已经感觉系统有些，说明CPU使用率高很可能真的已经影响到了系统的整体性能。
下面我们来看TOP EVENT：
CPU TIME排在第一位，这意味着系统中可能存在高开销的SQL。排在第二位的很是让人意外，居然是LOG FILE SYNC,而且平均等待时间居然高达58毫秒，这对于写操作的事务肯定产生了较大的影响。第三位的是TX锁，可能受到其他因素的影响，也可能应用本身就有很多争用。排在后面的两个是集X相关的等待，平均指标也不太好。
既然存在LOG FILE SYNC等待，我们就有必要马上看看LOG BUFFER的配置，才不到10M，确实是比较小。不过每秒REDO才185KB，这个BUFFER大小也还能应付。下面我们需要去分析LOG FILE PARALLEL WRITE的情况：
才3毫秒，看样子LOG FILE SYNC等待50多毫秒确实是有些不合理。这可能和GCS/GES性能有关，看看相关指标：
每秒INTERCONNECT流量才1826K，不高，不过CR BLOCK和CURRENT BLOCK的RECEIVE TIME都不太好，超过100毫秒。
消息传输的指标也不尽如人意，通过队列发送的消息延时居然高达99毫秒左右，而且有35%的消息是非直接发送的，35.96%出现了流控。RAC的性能指标为什么会这么差呢？这肯定会对应用产生较大的性能影响。不过RAC集X通信性能差也有可能是CPU使用率过高引起的。
从WAIT CLASS上看，系统等待的消耗多是在集X上，其次是提交（和LOG FILE SYNC等待有关，也可能受到集X性能的间接影响），第三是应用。
从等待事件上看，情况还是挺复杂的，甚至出现了DFS LOCK HANDLE等待，单块读的平均延时也不太好。调整LOG BUFFER之类的操作暂时还无法完成。现场用户发现营业厅压力开始大起来，业务部门反映一些营业厅的窗口排队的人也多了起来，希望我们尽快解决问题。
于是在这种复杂的情况下，降低CPU使用率成为解决当前问题的关键。于是我不再耽误时间，直接查看TOP SQL：
几条INSERT语句可以先不管。重点看看这几条DELETE语句，发现这几条DELETE语句都是走全表扫描，于是马上做了个awrsqrpt。
执行这么频繁的语句居然走全表扫描，于是我们确定马上建一个索引，降低这几条语句的逻辑读，缓解CPU使用率。由于系统十分繁忙，这个建索引工作尝试了多次才成功（业务高峰期不敢ONLINE模式创建索引）。索引创建后，CPU使用率立即降低了30%以上。很快，营业厅反馈系统性能有了较大好转，业务人员能够接受当前的性能了。
实际上这个案例，到解决之时还是没有彻底搞清楚问题的根源。主要是两个原因，一是我们是通过远程支持解决问题的，对于DFS HANDLE方面的问题没有做任何分析，另外一个原因是业务部门需要尽快解决问题。于是我们选择了采用见效最快的方法去做处置，对于DFS LOCK HANDLE,单块读延时过高，GCS性能问题等都没有去做深入分析。不过有时候生产系统，也只能这样了。