注:以下言论只代表个人观点，不代表公司意见或者是看法：
240块73G*15K的硬盘，128G的cache，支撑到17000iops的时候，存储就成瓶颈了，单个IO的响应时间居然超过100ms，如果一个语句有100个物理io，那么响应时间将是100*100=10,000ms，也就是10s种才能返回结果，TMD，也太恐怖了，差的有点离谱。
这个转折不是线型的，可能在15000iops的时候，你发现单个io的响应时间还在20ms以下，16000的时候，已经有50ms了，17000的时候，可能就100ms了。也就是说，拐点就在这里出现了，如果一个小的iops的增长，将导致大量的io响应缓慢，再导致所有的应用响应缓慢，再导致整个系统的处理能力下降。。。。。。
造成这么差的原因总是多方面的，但是，根据个人经验的长期总结，有如下2个重要原因
1、cache机制有问题，这款号称最高端的存储采用了令人可笑的cache设计，256k的cache size，也就是说，如果数据库发生了一个8k的io，存储将分配256K的cache size给它，那256-8K的地方呢？空着呗，除非有另外的访问读取了这个8k附近的数据。（这里解释一下，一个cache size所保存的数据，在磁盘上必须是连续的，而且起始地址也是固定的，是为了寻址的设计要求）。
那么，对于一个总是有很小IO，如数据库系统，IO又很离散的话，那么，你将遭遇到令人吃惊的存储命中率，如10%的命中率，对于一个128G的cache，数据库总大小也就1个T的环境来说，是不是太离奇了。
当初我为了跟踪这个问题，几乎是找遍了所有的资源，才得到这个信息，也只能说HDS对中国的技术封锁还是太严重，那么，想修改这个尺寸可以吗？回答是，可以，可以从256K修改成64K，但是需要停机，完全停机！但是，对于一个99.99%的高可用系统，停机一次是一个非常大的代价。
2、算法的设计也有问题，因为存储的瓶颈不在硬盘，我们可以计算每块盘的iops，大致为17000*0.9/200=77左右（90%不命中，200块盘用于数据文件），也就是说，一块盘的iops才77个，存储就如此不行了，一个硬盘，正常可以支撑到120 iops还没有问题（我们都是raid10，而且肯定没有热点硬盘或者热点raid组）。
那么瓶颈在哪里呢，其实我也不是太清楚存储的代码与算法设计，但是，我们比较一个数据，总会有点眉目：
如一个RAID组，分成2个部分，我们就假定part1、part2。当part的iops为150的时候，part2的iops才30，那么，虽然是同样的raid组，虽然part1的命中率比part2要高（part1 15%，part2大概5%），但是，part2的响应时间能保证在10ms，而part1则可能就是50ms甚至更高。
这里说明了什么问题？
很有可能这里就是瓶颈的所在，一个逻辑磁盘，也就是USP的ldev，当接收到一定量的io的时候，产生了瓶颈，发生了严重的等待，甚至是拐点的出现，但是，这个等待不是发生在OS上的，确实是发生在存储内部的，因为以上的数据来自存储本身的监控数据，而不是OS的数据。
如果是存储本身的ldev只能支撑到一定的IOPS，那么，我只能是猜测，存储给一个ldev，分配的资源是有限度的，或者说，一个ldev中存在一个有限的队列，当不能处理超过这个队列的数据时，就发生了严重的等待与拐点。
但是，如果确实是这样，当初设计规划的人，有谁知道这个问题呢？国内的代理厂家？他们根本不懂这些，能帮你装上就不错了，其它的，只能是靠自己了，其实，我们的ldev也不少，一个主机有48个，每个50G，如果这样的话，看样子当初只能规划为每个20G了。但是，增加ldev的数量是否一定能解决这个问题呢？这个天知道。
补充2点，1关于cache size的问题，只是在有些微码版本上是这样，新的微码是64K的，不过升级微码我没有发现有命中率的变化。2中关于怀疑ldev是否有队列的问题，厂家不承认有这个问题。
9i的时候，根据时间来做flashback query，是很容易有比较大的误差的，不过幸好的是，10g改进了这一点，其实，主要的原因是因为，9i 的scn与时间的同步问题，需要5分钟以后才能同步，也就是说，如果新插入的数据，还不到5分钟，马上就根据时间来flashback query，是查不到数据的。我们下面来看一则误差是怎么产生的：
11:22:08 Piner@9iR2>select * from test;
A
———-
1
2
3
11:22:11 Piner@9iR2>select to_char(sysdate,’yyyy-mm-dd hh24:mi:ss’),
to_char(DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER) from dual;
TO_CHAR(SYSDATE,’YY TO_CHAR(DBMS_FLASHBACK.GET_SYSTEM_CHANGE
——————- —————————————-
2007-04-09 11:22:25 54561295523
11:22:28 Piner@9iR2>delete from test;
3 rows deleted.
11:22:35 Piner@9iR2>commit;
Commit complete.
11:22:39 Piner@9iR2>SELECT * FROM test AS OF TIMESTAMP
TO_TIMESTAMP(’2007-04-09 11:22:25′, ‘YYYY-MM-DD HH:MI:SS’);
A
———-
1
2
3
11:23:41 Piner@9iR2>SELECT * FROM test AS OF SCN 54561295523;
A
———-
1
2
3
11:24:08 Piner@9iR2>insert into test values(1);
1 row created.
11:24:48 Piner@9iR2>insert into test values(3);
1 row created.
11:24:55 Piner@9iR2>insert into test values(5);
1 row created.
11:25:01 Piner@9iR2>commit;
Commit complete.
11:25:04 Piner@9iR2>select * from test;
A
———-
1
3
5
11:25:08 Piner@9iR2>select to_char(sysdate,’yyyy-mm-dd hh24:mi:ss’),
to_char(DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER) from dual;
TO_CHAR(SYSDATE,’YY TO_CHAR(DBMS_FLASHBACK.GET_SYSTEM_CHANGE
——————- —————————————-
2007-04-09 11:25:17 54561295583
11:25:17 Piner@9iR2>delete from test;
3 rows deleted.
11:25:21 Piner@9iR2>commit;
Commit complete.
11:25:23 Piner@9iR2>SELECT * FROM test AS OF TIMESTAMP
TO_TIMESTAMP(’2007-04-09 11:25:17′, ‘YYYY-MM-DD HH:MI:SS’);
A
———-
1
2
3
11:25:36 Piner@9iR2>SELECT * FROM test AS OF SCN 54561295583;
A
———-
1
3
5
11:34:02 Piner@9iR2>SELECT * FROM test AS OF TIMESTAMP
TO_TIMESTAMP(’2007-04-09 11:30:17′, ‘YYYY-MM-DD HH:MI:SS’);
A
———-
1
2
3
