主要的等待事件并没有发生大的变化，从等待事件的明细情况来看，db file sequential read的平均等待时间为14毫秒，和优化前差不多，没有感觉到很明显的IO性能提升。不过CPU的使用率已经大幅度提升了，今天业务高峰期间，CPU使用率一直接近100%，r队列在20左右，对于一个只有8 CPU的系统来说，这个值也已经比较危险了，虽然暂时并没有因为CPU问题造成大的性能问题，但是如果系统的负载再增加一些，就很危险了。从文件IO上看

H_SP_DATA                /dev/vgnew01/rh_sp_data01

       126,871      35   84.3     4.0        4,319        1      3,155   57.0

                         /dev/vgnew01/rh_sp_data02

       137,582      38   81.1     3.8        2,963        1      4,166   57.5

                         /dev/vgnew01/rh_sp_data03

       230,139      64   77.7     2.4        5,888        2      4,542   47.2

                         /dev/vgnew01/rh_sp_data04

        99,319      28   79.5     3.6        2,748        1      4,196   47.4

                         /dev/vgnew01/rh_sp_data05

       137,021      38   93.3     5.5        2,208        1      4,654   58.1

                         /dev/vgnew01/rh_sp_data06

       146,115      41   94.0     5.3        2,508        1      3,997   56.4

                         /dev/vgnew01/rh_sp_data07

       157,663      44  109.4     5.9        2,819        1      4,193   62.3

                         /dev/vgnew01/rh_sp_data08

       406,637     113  101.7     2.1       17,795        5     13,266   70.1

工单表所在的表空间的文件IO性能仍然不容乐观。虽然部分表空间的IO性能有所好转，但是存放工单表所在表空间的存储设备性能明显存在性能问题，这些文件是存放在VA7400上的，没有迁移到新扩容的EVA 3000上。而EVA 3000上的数据文件的IO性能目前还不错

H_SP_INDEX               /dev/vgora02/rh_sp_index01

        63,695      18   12.2     1.0       10,589        3        407   21.1

                         /dev/vgora02/rh_sp_index02

        55,789      16   11.4     1.0       13,100        4         18   12.2

                         /dev/vgora02/rh_sp_index03

        62,128      17   12.1     1.0       10,249        3         27    9.3

                         /dev/vgora02/rh_sp_index04

        58,787      16   11.8     1.0        9,540        3         24   14.2

                         /dev/vgora02/rh_sp_index05

        56,624      16   11.4     1.0       12,091        3          2   10.0

                         /dev/vgora02/rh_sp_index06

        61,264      17   10.6     1.0        8,437        2          2   20.0

                         /dev/vgora02/rh_sp_index07

        88,481      25   12.8     1.0       11,215        3      5,365   14.1

                         /dev/vgora02/rh_sp_index08

        77,852      22   12.8     1.0       13,984        4      4,554   13.7

                         /dev/vgora02/rh_sp_index09

        25,794       7   13.3     1.0        9,502        3        156   14.5

看样子Richard的IO优化并没有达到效果，两个存储之间的IO负载并不均衡，老的VA 7400出现了明显的瓶颈。正在这个时候，我收到了Richard的一封邮件。Richard对今天系统的IO表现感到满意，他认为系统的IO性能得到了明显的提升，通过glance的观察，IO等待队列明显下降。不过他也发现了VA 7400性能不佳的问题，建议将部分VA 7400上的数据文件转储到EVA 3000上。今天Richard他们公司的存储工程师对IO进行了半天的现场监控，发现EVA 3000还有很大的潜力，所以他们准备在近期再在EVA 3000上扩容6块硬盘，以便将更多的数据文件迁移过来。

我收到Richard的邮件马上给他回了一个邮件，把我的担忧和他说了一下，这回IO优化，在我眼里是完全失败的，IO性能虽然有所改善，但是并不是本质性的改善，危险的是CPU使用率已经相当高了，目前我们面临很大的风险。

Richard这家伙可能就在电脑边，我的邮件刚发给他，几分钟后就收到了他的邮件，Richard的意思是他的总体思路没问题，不过在细节上还是出现了一些问题，没想到VA 7400的性能这么差，如果把VA 7400上的部分数据文件移到 EVA 3000上，VA 7400的性能也会大幅度提升，这样IO优化就可以顺利结束了。

按照Richard这么折腾下去，这套系统早晚是会出问题的，现在幸亏VA7400性能不佳，CPU还没有出现致命的瓶颈，真的让Richard继续优化下去，IO的问题解决了，CPU的问题又出来了，这样风险更大。按照今天的业务量，如果再提高15%左右，就算Richard不折腾，CPU也可能出问题。于是我马上打电话给老万，让他尽快想想办法，让开发商做些动作，减少一点SQL的开销。老万接了我的电话后，马上把开发商的现场经理大董找来，我们三个人开了一个电话会议。大家想了一圈办法也没想到什么好办法，于是我想到了平安保险的做法，在业务高峰来临的时候，为确保主生产系统的性能，临时性关闭部分不常用功能。于是我建议老万能不能临时关闭部分功能，比如查询功能。

大董想了半天，只想出几个开销不是很大的模块，关闭这些模块能够减少的负载有限，对于整个系统来说，简直就是杯水车薪。突然大董叫了起来：“有办法了，我们干脆限制一下工贸公司统计的时间范围，以前我们限制统计不能超过1个月，后来由于业务人员强烈要求，才把统计查询的时间限制临时去掉了。要加上限制，只需要调整一下配置，把那个开关打开就行了，连应用都不用重启。”

我一听十分高兴：“对啊，我还忘了这茬了，1月份的时候我们就打开过这个限制，才渡过了春节前的高峰期。如果把这个限制打开，起码可以减少10%的系统开销。”

结束了三方通话，已经是6点多了。我刚刚盛了一碗饭准备坐下来吃饭，老万的电话又打进来了。他还是对系统不太放心，问我有什么好办法。

我目前也是很无奈，优化那边，明喻已经安排了Richard来做，我是插不上手的，顶多能给Richard一点建议，但是Richard好像对我的建议并不在意。我目前觉得如果要防止Richard的优化带来更大的问题，一定要让大董他们尽快优化一些应用，而从目前来看，大董他们很难在短时间内对应用做较大的优化。今天打开查询时间限制这个方法应该是近期大董他们唯一能做的事情了。

老万失望的放下了电话。从老万唉声叹气的表情看，这几天他的日子确实不好过，今晚可能又要失眠了。但是我能做的也只有这么多了，这个时候安慰他，可能是在害他。