1.1.1. 5月12日 Richard的180度大转弯

5.1长假后，系统的业务量比较平稳，Richard也对IO进行了几次小的调整，移到EVA 3000上的文件的IO性能都比较好，但是留在VA 7400上的文件IO仍然很慢。我和老万都有点怀疑是不是VA 7400出了什么故障，HP的工程师也到现场做了几次检查，没有发现什么问题。昨天晚上Richard把剩余的几个数据文件全部移到了EVA 3000上，现在VA 7400上只剩下UNDO表空间和TEMP表空间的几个文件了。从IO性能上来看，经过Richard的一系列优化后，确实明显有了提高，文件系统IO的性能有了不小的提升。虽然IO性能有了较大的改善，但是CPU的负载一直都没有降下来。虽然开发商对查询的时间做了限制，限制统计查询不能跨月。这个限制打开后，刚开始的几天CPU使用率还有明显的下降，不过随着这几天IO性能的优化，以及系统负载逐渐增加，这几天CPU的使用率又增加到了100%。

今天早上我正在刷牙，明喻就打电话来问我，Richard和我昨天交流了些什么？我说没有啊 ，前几天给Richard发了个邮件，告诉他CPU可能会吃紧，Richard还觉得我的担心是多余的。

明喻告诉我，肯定是我的这个邮件惹的事，今天一早Richard就给明喻发了个邮件，建议对老万他们的系统进行扩容，而且CPU内存都要扩，否则这套系统无法渡过今年的业务旺季。

我一听也感到十分意外，前几天Richard的态度还很乐观，怎么今天一早就180度大转弯了呢？看样子Richard是看明白了摆在他面前的问题了。老外再一根筋，起码的理智还是有的，Richard有这个态度，后面的事情就很容易办了。Richard态度的大转弯让明喻感到十分不爽，本来这个项目在明喻的公司里就被很多人诟病，甚至有些领导在会上都建议宣布这个项目失败，不再追加项目投入了。如果真的像Richard要求的那样去扩容，估计明喻在公司里的日子就很难过了。花了几十万请Richard过来，最终的结果反而是再投入大几十万进行扩容，这个结果应该是最坏的结果了。

接下来明喻想要和我讨论什么，我猜都能猜得到，所以没等明喻开口，我就主动说出了明喻想说的事情：“明喻，现在开始启动应用方面的优化，已经有点晚了，我真的一点把握也没有。”

明喻说：“老白，这回我是真下决心了，如果你能保证5月底完成优化，需要多少钱都好说。”

我回答明喻说，钱不是关键的问题，关键是现在已经5月12号了，5月底业务高峰就来了，只有差不多20天的时间来做应用的优化，风险太大了，我不敢承担这个责任。目前来看，还是Richard的方案比较靠谱。现在来做硬件扩容，如果准备充分，半个月时间肯定能搞定，还赶得上在业务高峰来临前解决这个问题。老万的解决问题的期限是5月30号，现在做扩容，老万也不会有任何意见。而现在开始做应用优化，这么复杂的系统，还需要大董他们配合，软件修改了还要测试，这么短的时间，很难保证不出什么问题。

明喻看我态度比较坚决，也就没有再坚持。和明喻通完电话后，我打开了电脑，查看了一下邮件，发现昨晚Richard给我发了一封邮件。邮件内容大致是：Jackson，IO问题解决了以后，我感觉我已经没有时间来解决CPU的问题了，这个系统远比我想象的复杂，明喻开始给我的信息误导了我，前些天我看到你的邮件才意识到问题的严重性，因此我准备建议公司立即进行硬件扩容。在这个问题上，我们已经没有时间再犯错误了。另外VA 7400的问题我已经找到了，控制器的微码有问题，我们会在硬件扩容的时候一起做微码的升级，升级后部分数据文件可以回迁到VA 7400，这样IO的问题就彻底解决了。你的观点很有建设性，也对我帮助很大。我觉得要维持这套系统的稳定运行，必须进行应用方面的优化。我只是系统方面的专家，对于Oracle数据库的优化，我觉得你是真正的行家，我会建议公司和你合作继续进行应用方面的优化。希望能有机会和你见面。

我通过QQ把Richard的来信发给了老万，老万看到这封信后十分高兴，如果真的扩容4个CPU，4G内存，那么今年渡过业务旺季就没有问题了。我提醒老万，虽然Richard提了建议，不过这个项目的项目经理是明喻，必须让明喻尽快做出扩容的决定，否则时间都来不及了。

下午的时候马工发来了今天的Statspack报告，随着报告还写了一小段文字：

老白，您好！

从本周开始，有网点和工贸已经开始投诉系统速度慢的问题了，但是从报告中的平均响应时间来看还蛮好的嘛，看来他们的好生活还不能过太久，稍微一点不舒服就抱怨了。

只是这两天外网端口重启又频繁了起来，平均每天都会有一个端口要主动重启。

看来系统自4月10日到5月10日的良好表现期已经要结束了。

我马上查看了一下今天上午的STATSPACK报告，TOP 5 EVENTS有了明显的变化，LATCH FREE有了较大的增加：

Top 5 Timed Events

~~~~~~~~~~~~~~~~~~                                                     % Total

Event                                               Waits    Time (s) Ela Time

-------------------------------------------- ------------ ----------- --------

db file sequential read                        11,832,404     168,204    56.25

latch free                                      3,245,207      77,591    25.95

CPU time                                                       23,908     7.99

db file scattered read                            389,737      22,638     7.57

buffer busy waits                                 286,856       2,590      .87

从平均事务响应时间来看，今天上午9点到10点间的平均事务响应时间是1767毫秒，下午3点到40点间的平均事务响应时间是2264毫秒，都比前几天稍微差一些，不过和3月底4月初4-6秒的平均事务响应时间相比还是好了不少。看样子马工说的不错，过了几天好日子，胃口就高了很多。从db file sequential read的平均时间来看，今天上午是14毫秒，下午是13毫秒，IO的性能基本上没有太大的问题，和前阵子比较有了很大的提升，Richard对IO的优化还是很见成效的。

不过今天的LATCH FREE等待十分高，上午的时候是25.95%，下午上升到33%。从Statspack报告上看，LATCH FREE主要集中在cache buffer chains、cache buffer lru chains和library cache、row cache objects等方面。由于CPU资源的不足，导致了闩锁争用日益严重。同时由于CPU资源的不足，导致我们无法通过加大DB CACHE等方法来减少相关闩锁的争用，因为加大DB CACHE的大小会带来更大的CPU开销，从而加剧CPU的争用。实际上Richard的扩容建议是目前解决系统问题的最佳方法，从他扩容CPU和内存的建议上看他已经对后续的调整有了一个初步的思路。

不过扩容对于明喻来说是比较痛苦的事情，因为目前的CELL板上已经没有足够的插槽，所以如果扩容就需要扩充一个扩展机箱，这么算起来，明喻他们公司要在这个项目上增加上百万的追加投资，对于目前已经在公司里抬不起头来的明喻，真是雪上加霜啊。

吃晚饭的时候，我接到了明喻的电话，邀请我明天过去参加下午的项目情况分析会议。这个会议规格很高，除了老万他们部门外，明喻的领导、老万的领导都会参与这个会议。在这个会议上，将要讨论Richard提出的硬件扩容的问题。明喻希望我能够配合Richard，让领导立即拍板进行扩容。