ismiami

使用HDS USP，所以关注中，学习各位见解

klin121628

引用:

原帖由 truthistruth 于 2008-5-7 17:04 发表
透过这几次评标和以前的使用经验简单评测一下各个厂商的产品供参考（各个厂商高端存储EMC DMX4 HDS USP IBM DS8300）：总体感觉EMCDMX和HDS USP在同一水平，IBM DS8300就比较弱了USP和DMX都采用新的结构设计，而DS80 ...

8000坏一个控制器会损失一半cache，但并不代表会损失一半性能。说点服务器的内容，你见过哪个系统SMP系数是按照2来算的？更何况2个570并不是做级联
要说架构，真是永远也争吵不完。IBM又不是做不出多控制器的存储

mike79

引用:

原帖由 klin121628 于 2008-5-8 13:46 发表


8000坏一个控制器会损失一半cache，但并不代表会损失一半性能。说点服务器的内容，你见过哪个系统SMP系数是按照2来算的？更何况2个570并不是做级联
要说架构，真是永远也争吵不完。IBM又不是做不出多控制器的存 ...

LZ可能对存储不太熟悉，而架构这些词听上去又比较有技术含量，所以......
我对存储也不太熟悉，但还是认为架构什么的是在忽悠人。

marco

引用:

原帖由 shahand 于 2008-5-7 15:18 发表
林总：两个补充

taobao测试的时候好像没有涉及oracle的sga，因为使用orian模拟的

另usp不是配置了128G的cache么

他们的方法就是叫CACHE不命中，压力全在硬盘上

Frank

17000iops,如果按每个15K FC硬盘150 IOPS算，120个左右就已经到硬盘极限了。显然是不通过cache直接压到硬盘的结果。

不晓得怎么关闭的cache？
另外如何能看到cache命中率呢？ 开启和关闭的性能做对比么？？  

如果使用cache，不考虑算法等问题，单就cache size看，这种测试IBM DS8K的成绩会很高。HDS、EMC的都太大了，OLAP下，oracle大多是离散写，而且都是小数据块。

[ 本帖最后由 Frank 于 2008-5-8 17:59 编辑 ]

piner

我基本不上该论坛，是别人告诉了我这个帖子，我才过来的。我觉得有必要解释一下，因为也不想被别人误解。

至于林肯，我知道你是谁，有空欢迎来这里交流，我随时欢迎

我只公布2组数据，真实应用下的数据，我们也别扯什么测试不测试。

1。sun 9990 相当于hds usp 600
240 15k disk,128G cahce,数据库大楷跑在200块盘上，其它的是archive与hot spare
跑到17000 IOPS出现拐点，应用很慢
厂家来调整，一直没有好转，一直到最后，退出我们的生产环境

2。DMX3
240 15k disk,160G cache，数据库也差不多在200块盘上，分布方式一样，主机端与dhs也一样
高峰时期最高曾经跑到40000 IOPS，响应时间虽然也比较慢了，到了20ms，但是不至于象HDS usp出现拐点。

piner

至于测试，我也解释一下。
因为我们真实的压力，全是离散读与单块读，所以，我们的测试就是这个目标，仿真最真实的环境，降低SGA，其实我并不希望这样，当初是因为主机档次不行，才强行降低SGA让磁盘能更多的参与工作。其实降低SGA，能大大增加存储的命中率，如果SGA很大，存储的命中率会直线下降（我想道理很简单，大家应当能想明白吧）。

实际情况呢？？？因为我们的业务是离散读，HDS的cache命中率基本在10%左右，DMX3基本在20%左右（大家注意，hds是读写镜相分离，dmx3是全镜相，按照有些人的算法，DHS的读cache应当更大）

所以，测试的时候，测试硬盘的性能，这才是我们的测试目的，不象厂商，全是测试cache命中，但是，那都是理论的数据，实际情况不会发生的话，有啥意思呢？

orion就是一款很好的测试工具，在测试离散读的时候，存储的cache命中率是低于1%的。而这种效果，就是实际应用中，可能达到的最差的效果，如果在cache命中1%还能工作良好，那么，正常应用肯定工作良好。

注意，我所说的正常工作，还是我开始强调的，我们的业务类型，全是离散读的应用，至于连续读，那么是另外的应用类型。

[ 本帖最后由 piner 于 2008-5-8 23:17 编辑 ]

host

正主出现了，看来一切才算明朗一点了。

也不枉我被删的帖子了

林肯

引用:

原帖由 piner 于 2008-5-8 22:51 发表
我基本不上该论坛，是别人告诉了我这个帖子，我才过来的。我觉得有必要解释一下，因为也不想被别人误解。

至于林肯，我知道你是谁，有空欢迎来这里交流，我随时欢迎

我只公布2组数据，真实应用下的数据，我们也 ...

谢谢piner给面子来讲两句，你能过来，很多事情好办了，都清楚了，以技术讨论技术才是最欢迎的。因为这才是最纯粹的，也可以屏蔽掉很多不必要的杂音和猜测（为了保持论坛干净，我已经删除了那些别有用心人生攻击的贴子），甚至被某些人利用，那就是最大的悲哀了（就像B公司的CEO现在和A公司的CEO现在在博客上面互相人生攻击，A公司的CTO跳到B公司后，由于语言不断口水战不断，变成IT的笑柄，他们都是忒有身份的人啊）
1 请注意前面的所有帖子都是针对技术的解释，和针对其它人的回复，没有任何针对性
2 针对你的假设，我还是那就话，不同的设备使用的方法是不一样的，全部打散的机制可能对于E种阵列使用是可以的，但是对于H种设备不一定是best practice，更何况在你的贴子里面也可以清楚地看到，所有的data placement和相关服务，你们并没有得到原厂的服务，而是被另外的一些工程师在负责（他们很敬业，但是对你特殊的应用不一定很有经验），最正确的best practice我相信H厂商的人是有发言权的，因为毕竟IO是在H厂商的阵列里面跑
3 如果不是有人贴出这个贴子，也就不会有现在的更多的讨论，几年前你写这个贴子同样是为了讨论技术，可以看出回帖也很多，可以看出你也很负责，刚刚注册来回这个贴子，因为纯粹讨论技术的人是不愿意看到自己的东西被人恶意利用的，但是至于几年前的这个具体case的情况涉及到商业case，我会和你单独交流；
4 所有的猜测和怀疑，我对于这个贴子技术上的回答到此为止。还是那句话，这里是切磋技术的地方，而不是玩政治的地方；非常bs那些没有素质恶意攻击的马甲（身为版主，我义不容辞地把他们清理出去）！！！

[ 本帖最后由 林肯 于 2008-5-8 23:52 编辑 ]

林肯

引用:

原帖由 host 于 2008-5-8 23:20 发表
正主出现了，看来一切才算明朗一点了。

也不枉我被删的帖子了

这么晚不睡，就你多事，不好好工作，看热闹第一，BS