EMC cmx950 和IBM DS8100 性能哪一个更好一点

biti_rainy

最初由 orian 发布\r\n[B]128G/1T 正好10%啊，哈哈，谁家的存储，谁家的应用，能做成这样？！！！\r\n\r\n现在应用的读也太疯狂，动不动就几个G的数据扫一遍，性能不好也没办法。只能看直接磁盘读的iops，不过很少有人公布的。 [/B]

\r\n\r\n1: 应用基本都是小io 了，oracle数据库的oltp ，怎么可能几个g 的数据扫描，那样早翘了。\r\n\r\n2：存储么，不都是流行的大厂家么。 这样子，让人怎么不担忧呢。 没办法只好换一家看看了！ 下半年看效果！

orian

小io,一个怎么也有4k吧？1000个iops是一秒钟4M, 1,000,000个iops可就是1秒钟4G了！\r\n你的机器跑了多少iops? 总不至于只有几千吧？通常都是几万到十几万的数量级，一秒钟都要扫几百M数据的，一个查询持续个几十秒，尽管还有别的session参与，但它也要读不少吧？

biti_rainy

最初由 orian 发布\r\n[B]小io,一个怎么也有4k吧？1000个iops是一秒钟4M, 1,000,000个iops可就是1秒钟4G了！\r\n你的机器跑了多少iops? 总不至于只有几千吧？通常都是几万到十几万的数量级，一秒钟都要扫几百M数据的，一个查询持续个几十秒，尽管还有别的session参与，但它也要读不少吧？ [/B]

\r\n\r\n\r\n不是我的系统，一个io  8k ，存储只能支持到 16000 个 iops就不行了……上到17000的时候 io响应从不到30ms 一下子上升到100ms以上。  16000*8k=128MB。 \r\n这当然不是一个进程，是总共有几千个数据库连接的oltp。

orian

100ms也还顶得住，哈哈，就慢点呗。我都见过1000多ms的，第一次见到的时候被吓坏了，从来没有考虑过是否存在fc timeout的，现在要考虑timeout 是不是能顶得住了！

cobalt

1、计算一次物理磁盘所能达到的IOPS值。240块盘，除了4块热备外，还剩下236块可用。假设都用RAID10（2D+2D），能做59组PG。假设都是4-8k的block，每个73G15K磁盘理论Read IOPS为170，Write IOPS为160。因此59组PG能提供的Read IOPS为236*170=40120 IOPS，Write IOPS为118*160=18880。\r\n\r\n你的业务应该是支持在线业务的OLTP，USP600只能支撑16000个IOPS的话，那么说来，数据应该没有跨越所有的PG。假设每个LDEV大小为33G，1T数据正好跨越一半的PG，理论IOPS怎么也有2万，打个8折也就是16000，哈。\r\n\r\n另外，每个PG是否都很忙？响应时间这么差，是不是WPD值也很高？30-40%？\r\n\r\n对于80%是读动作的OLTP系统来说，Cache命中率低到10%，应该跟数据分布有一定关系。这个10%是所有的PG都一样？\r\n可以的话，把LDEV/LV/LV Stripe大小/DB Tablespace的对应关系研究一下，相信能找到一些原因。\r\n\r\n2、对于厂家公布的IOPS值，自然应该就是Cache IOPS。USP1100宣称的IOPS值为200万，Total Cache配置为256G，镜像后为128G。对于USP来说，最小的Cache单位为一个segment，对于open系统，大小为32个blocks，即64K。因此128*1024*1024/64=2097152，正好200万，哈。\r\n\r\n3、对于你的USP600，应该是配置了两个DKA吧。Total Cache 128G，理论IOPS为100万，哈。\r\n\r\n4、给这个系统分配了几个CHA端口？是独占每个CHA的MP吗？CHA的MP busy程度多少？如果分配了2个独立的CHA端口，且I/O正好为8K的话，每个CHA端口能提供的IOPS为9000，MBPS为70，因此两个CHA端口能提供的理论IOPS为18000，打个8折（MP Busy达到80%后性能下降），大概为14400，所以猜测你的应用是4个Port支撑，否则就是已经跑到了端口的极限了，哈。\r\n\r\n5、在整个数据流过程中，数据到HBA卡的buffer后经过SW到达CHA的buffer，然后再到Cache。CHA的buffer到Cache是电路交换，比传送路径中的其它组件传输时间要短，因此不会构成性能瓶颈。

orian

撞到小马枪口上了！哈哈哈哈

biti_rainy

因为不是我负责的系统，我也无法太仔细的回答\r\n\r\n只能说 用户的业务数据 几乎是比较均匀分布在所有 磁盘上的，磁盘之间几乎没有特别繁忙和特别空闲共存的情况。\r\n\r\n\r\n用户实际有3个数据库跑在存储上（3个数据库是同一个系统，为了压力而分了3个），一共是6块hba卡 接到 san switch，存储端 好象总共是使用了 48个port （lun分组输出到不同port 对应到不同的zone）。\r\n\r\n\r\n关于 hds 的 cache 的单元，这是我们质疑的，在9970 or 9980 上，openv是64k。 但是usp 出来的时候是256k，这个问题应该是被我们质疑的重点位置。命中率低的这个东西要负比较大的责任。据说最新出的usp系列中微码做了修改，已经用回 64k了。 估计就是实际表现不佳而退回去的。   \r\n\r\n另外一个问题就是厂商现在又来怀疑 系统的数据均分到所有磁盘，可能带来性能问题。 应该将数据相对地集中，让一部分磁盘繁忙而使得命中率可能提高(具体可以反应在vg的创建对应的磁盘数量以及vg中 stripe  width的选择)。 但这个建议几乎不大可能在系统中重新实施。 所以也无法证明。\r\n在其他测试系统中，不管是hds  usp还是emc  dmx3 ，我们在测试过程中都是数据尽量分散（lv  也stripe 到尽量多的pv）的情况下表现好一些。 所以一直也难以在测试中支持  数据相对集中而带来cache命中率的提升的想法。

orian

谁是操作系统的adm? 把操作系统的情况详细描述一下\r\n\r\n拿filemon看看各个lv的使用情况\r\nlslv 和 lslv -m 看看lv的分布\r\n然后再做推论，现在都是在猜想

biti_rainy

最初由 orian 发布\r\n[B]谁是操作系统的adm? 把操作系统的情况详细描述一下\r\n\r\n拿filemon看看各个lv的使用情况\r\nlslv 和 lslv -m 看看lv的分布\r\n然后再做推论，现在都是在猜想 [/B]

\r\n\r\n虽然不是我负责的系统，但是系统上线前的规划，大家一起讨论的。 都使用 raw device ，stripe size  128k, 一个 vg 8 个pv ，意味着一个lv 分布在 32 块磁盘上。\r\n 而数据库的文件也尽力跨在不同 vg 上均匀分布为准。\r\n\r\n这个事情，厂商来人n次调查分析了很久，他们联系国内外资源，折腾了大半年，为这个事情厂商还联系资源让这边的人去北京专程模拟测试，也没有明显进展，已经升级成了重大矛盾。

cobalt

usp是1个slot=4个segment，每个segment还是64k。\r\n你的存储前端连接数目应该描述的有一些小问题。48个存储前端对应6个hba卡，每个磁盘有8个paths，太多了。\r\n\r\n既然厂家也出马了，看来还是有点难度，哈。不过也蛮有兴趣了解的。\r\n不知道能否看看performance monitor的数据？\r\nhds的北京机房可以满足小容量测试需求，性能测试就很难了。哈。\r\n\r\n太晚了，回头再回复。\r\n最后，感觉把lz的帖子都给毁了。跑题太远了，呵呵。