1.1.1. 4月30日 IO优化

今天早上没什么事，明天就开始7天的五一长假了，所以我今天和公司的同事打了个招呼，今天就不过去了。这个五一节并没有什么安排，只是准备6号的时候出去跑一趟短途，要么去桔钓沙游泳，要么去巽寮湾玩玩。早上躺在床上看了会电视，才懒懒的爬起来洗脸刷牙，吃完早饭的时候已经块10点钟了。打开电脑收了下邮件，发现马工发了一封邮件给我：

老白，您好！

自月中系统好转之后，明喻真又开始冗长的不着边际的动作了。

老万和明喻关于数据库方面增加费用的谈判也没有成功，按他的说法是明喻他们负责项目的这个部门准备放弃项目了，但是销售和客户部门却坚持要把项目继续下去，而继续项目的方法不是找你商量而是通过内部挖国内外资源的办法来进行，对于你的数据库方面的计划他们也没有任何回应，把我郁闷得......

18号那天我离开青岛开始休假，直到26日回青岛，这期间关于项目的事情我一概不过问，听之任之。

现在明喻他们的动作：

1、请了一个系统测试工程师准备进行实验室测试，以“科学”的数据得出一个系统和硬件的解决方案；

2、请了新西兰的数据库专家Richard来进行数据库方面的分析和优化，以得出一个数据库方面的优化解决方案。

目前第一个动作正在准备过程中，用的是LoadRunner软件，这两天东软在学习如何用LoadRunner准备测试脚本，非常不顺利，居然来教他们用LoadRunner的工程师对于如何根据东软现在的应用架构配置LoadRunner这一步都没能跨过去，两天了，没有什么进展。

第二个动作限于英语水平我没能跟老外有更多的交流，他有几个举措：增加EVA3000的4块硬盘、增加VA7410的3块硬盘以提高IO吞吐，昨天改了一个操作系统参数，虽然没有对数据库参数进行修改，但昨晚停数据库进行系统数据和应用数据DD复制，而后在数据库重起时东软居然发现参数文件找不到了，于是用了一个旧版本的，而且后来是在奕华的协助下把数据库给起来了，害我又没有睡好觉。今天中午老蒋说找到了原来的参数文件，要重启数据库。

老万的时间要求是必须在5月31日解决问题，但是明喻做法可真是有趣啊！

我读了邮件，马上给马工打了个电话，他对目前的情况比较悲观，在老万的压力下，Richard已经准备不经过严格的测试直接开始做优化动作了。他的第一个动作就是优化IO，明喻他们已经申请好了几块硬盘，今天晚上就要实施存储的扩容，按照Richard的想法，增加磁盘的数量，让IO分布到更多的磁盘上，可以提高IO的性能。另外Richard建议取消每个REDO LOG组的镜像，改为每个组一个member，以减少IO的负担。Richard 的做法是IO性能优化中常用的办法，我也经常使用这个方法，但是在老万他们这个系统里，目前不仅仅是IO存在问题，和IO相比，更为危险的是CPU资源。一旦IO性能得到提升，每秒钟将有更多的事务被处理，那样就要消耗更多的CPU资源，一旦CPU出现了瓶颈，闩锁争用将急剧上升，数据库的整体性能不会提高反而会有所下降。

刚刚和马工通完电话，老万的电话就打了进来，他告诉我今天晚上Richard想对IO进行优化，增加几块硬盘。Richard提出的取消一个日志组成员的建议被东软拒绝了，东软他们不愿意降低系统的可靠性来换取IO成本的下降。老万问我Richard的方案我是否赞成。

我说：“万科，如果纯粹是优化IO，Richard的做法无可厚非。不过按照目前系统的情况，单独优化IO风险很大，一旦CPU过载那么后果更严重。最好是能够首先减少一些逻辑读，再进行IO优化，两个步骤一起实施才能确保万无一失。”

老万实际上也有类似的担心，于是老万希望我能够给Richard发个邮件，把这个问题和Richard说一下，看看Richard能不能考虑的充分一些再做动作。于是我马上写了封邮件给Richard。写完邮件后，我发了个短信给明喻，让明喻通知Richard收一下邮件。通过第一次和Richard的口语交流，我对自己的口语能力基本上丧失了信心。

发完邮件后一看时间已经快中午了，由于早饭吃的晚，也没有心思做午饭吃了。冰箱里还有半个西瓜，就权当我的午饭了吧。吃完西瓜回到电脑边上的时候，发现Richard已经回了邮件：

Hi Jackson,

Just following up on this message, 

I agree that if we improve IO we will run into the CPU bottleneck. The CPU is very high now. 

My reason for fixing the IO first is if we upgrade the server to faster/more CPU then we will 

not get any more performance from the server as the additional resource will be waiting IO.

So I believe that we need to change both but to change them one at a time. IO is the bottleneck now, 

then only when this is removed will we raise the processing to become a CPU bottleneck. The question 

is if we can improve the IO performance will the system performance meet the customer needs without 

the cost of the server upgrade.

As to Memory the Oracle database has over 6Gb of memory now for SGA. If this is not enough then how 

large does the memory on this system need to be?. It is already 2Gb memory per CPU so is on the larger 

size. What would your suggestion for the system memory size?

As to the code, I agree it is not only hard but expensive. I am interested in your comments re the 

tuning that you plan to do. Mingyu do you know why this has been put on hold?.

Best regards

Richard

这封信是发给我，同时抄送明喻的，很明显最后一句"Mingyu do you know why this has been put on hold?"是问明喻的。在这封邮件里Richard认为CPU和IO都需要调整，但是必须一个一个做，他准备首先从IO调整入手。Richard认为IO调整单独做没有问题，这是基于封闭系统的理论，如果平均每秒事务的数量是固定的，那么像Richard所说的一样，CPU负载不会大幅度提升。另外一种可以这么调整的情况是CPU资源比较充足。但是目前的情况恰恰都不是这两种情况，CPU已经出现了较为严重的瓶颈，但是Richard并没有意识到这一点。我在给Richard的邮件中谈到了排队效用，排队效应这个词汇是我自己创造的，可能Richard并没有明白是什么意思，我把排队效应翻译成“effect of waiting queue”，当时觉得翻译的还有点靠谱，现在看来这不是一个很准确的翻译，起码Richard并没有看懂。

今天晚上Richard要在EVA 3000上增加四块盘，组成一个RAID 0+1，在VA7400上增加3块盘，组成一个RAID 5。Richard准备把REDO LOG移到EVA3000上新创建的这个RAID 0+1大的磁盘组上，同时从EVA 3000上迁移部分写IO较多的数据文件到这个盘组上。然后会将VA7400上一部分写入较少的数据文件移到VA7400上的新增的磁盘组上，以减轻存储的负担，提高IO的性能。Richard这个动作做的很漂亮，肯定能较大幅度的提高IO的性能，不过这也正是我所担心的，Richard这一手的效果越好我越担心，我担心这哥们会把我前一阵子花了九牛二虎之力才降下来的CPU负载再折腾上去。

下午的时候，马工又给我打了一个电话，他经过一番努力，希望劝阻今天晚上的盘阵扩容操作，不过最终还是失败了。明天是5.1节，这个系统的业务量肯定会比今天有所上升，而今晚这个操作让马工十分担心，如果明天系统真的出了什么问题，那么这个5.1节都过不好了。我正和马工聊着，突然马工说：“老白，你别挂电话，万科有话和你说”。

老万第一句就问我：“老白，明天你准备去哪里玩？”

我说：“明天能上哪玩去，5.1节哪都是人，出去玩？还不如在家睡大觉。”刚说完，我就觉得好像哪里不对。还没等我补充，老万就接上话了：“那好，老白，明天你帮我盯一下系统，今天晚上这个操作我是实在不放心，你在家就好了，我也就放心了。为了今天晚上的这个扩容，我明天也只能在办公室里了，我们明天一起聊QQ”。原来老万这个老狐狸在这里等着我呢，既然前面已经说了明天在家睡觉，我也就不好推辞了，只能答应了老万，明天在家上网，陪他聊QQ。