最近这段时间在参与一个优化项目，所以思考优化的事情比较多。因此最近的文章中，优化相关的内容会比较多，如果有朋友想看些其他方面的题材，可以留言告知。实际上我每天写的东西大多数都是前一天的思想内容，凭空找个话题来写上一篇，时间长了肯定会越来越空洞无物，我也没有那个本事，脑子里的积累写上几年还游刃有余。
关于优化中的大势判断前些年我也写过一篇，优化就像下围棋一样，需要在大势判断正确的情况下，做出很多提前布局，确保每一步落子都能获得相关支撑。比如我们想降低数据库的IO延时，或者锁冲突，那么我们首先要看看CPU资源是否充足。因为一旦IO延时降低，锁冲突减少，势必会让系统的并发执行量大大提升。如果系统中的CPU资源已经不足，那么解决其他问题之后，CPU可能成为下一个堵点，甚至可能引发更为严重的性能危机。
几年前我参与过一个系统的优化工作，当时以为是个小优化，所以没有进行统筹考虑，发现什么问题就去解决什么问题了。最初发现应用服务器的线程池等配置存在问题，本地磁盘IO性能不行，导致临时文件写入堵塞。解决这个问题后，数据库服务器的IO延时又不行了。在分析过程中，优化团队发现AIX系统中的HDISK的QUEUE_DEPTH采用了默认值。AIX系统对于非IBM存储的QUEUE_DEPTH十分坑爹，对HDS默认是2，而大负载的IO下，这个队列深度至少要设置16，甚至32。
优化项目组调整了QUEUE_DEPTH，没想到第二天业务高峰的时候，系统总体性能不升反降。原来单块读延时还只有10几毫秒，优化后反而变成29毫秒了。
幸亏团队中有十分强的存储专家，经过这哥们的一通分析发现，这个存储配备了64个前端端口，属于超豪华配置，但是这些端口的使用十分不均衡，有些端口上分配了十几台甚至几十台数据库服务器，而有十多个端口根本就没有接入任何系统。这套数据库系统映射的两个端口上都连接了十多台服务器，端口控制器的CPU使用率接近100%，处于过于繁忙的状态。于是优化小组重新配置了存储端口，找到2个空闲的端口用于本系统。经过调整后系统性能得到了极大的提升。
事后我和参加这个优化的几个老哥们说，我们这帮子老家伙，把一个优化项目做成这样，说出去真的太丢脸了。于是大家都相约对外绝不提这个项目。事情过去了十年了，现在再提起这个项目，不知道还有人记得不。实际上在一个存在较为严重问题的系统中，排队效应的问题是肯定存在的。因此没有优秀的大势判断加持，这种项目很容易做出事情来。
排队效应是我在十多年前的《DBA优化日记》中自己创造的一个名词，正是排队效应的存在，在一些性能问题严重，系统资源存在短板的系统的优化中，缺乏大势判断很容易引发较大的运维故障。除此之外，大势判断还在两个优化工作中可以发挥作用。一个是方案的取舍，另外一个是确定优化工作的阶段性终点。
优化方案的取舍对于专家来说并不是个问题，但是对于很多半专业的优化团队来说十分关键。前几天一个客户问我一个问题，他们一套ERP系统的CURSOR争用很严重，共享池总出问题，分析下来是SQL没用绑定变量导致了硬解析过高，想启用CURSOR_SHARING参数。我分析了一下他们系统的整体情况，觉得不太妥当。因为这事一套ERP系统，用了快10年了，没做过归档，很多上百GB的大表也没有分区，总数据量也已经超过20TB，数据库版本也比较老，是Oracle 11.2.0.4。这种系统如果启用CURSOR_SHARING=FORCE或者SIMILAR,那么BIND PEEKING很可能出错，导致某些SQL的执行计划错误。这套系统高峰期的CPU使用率已经达到100%，LOAD超过500,一旦CPU爆掉了，那么可能带来比硬解析更大的问题。从大势判断上，我建议他们不要使用CURSOR_SHARING来解决这个问题，还是选择老老实实的优化应用。
在判断某个优化任务是否要做的时候，大势判断也也十分关键。优化方案制定的时候，我们总是会把可以进行优化的地方尽可能多的列出来。有些优化工作是比较好做的，有些并不容易，做起来成本很高。在优化项目进行到中后期的时候，我们就需要判断哪些工作该做，哪些工作可以不做。当大势判断确定优化任务可以圆满完成的时候，有些风险较大、效果不明确、优化难度较大的工作就可以暂时不去做了。在二十多年的优化生涯中，我也遇到过几次想十全十美，最后变成画蛇添足的事情。2012年的时候，我给一个客户优化一个营业系统。当我们的优化工作进行到第二阶段的时候，预期的LOAD下降30%的任务已经超额完成了，整个系统的LOAD已经下降了50%以上，当时我果断的决定优化项目告一段落，第三阶段的应用优化工作暂时不做了。事实上，这套系统后来又运行了3年，到新的软硬件替代它的时候，一直没有出过大的性能问题。
大势判断决定了优化工作中的取舍，取舍决定了优化工作的成败，不得不小心谨慎啊。