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

piner

最初由 orian 发布\r\n[B]sorry, 楼上理解错误，我说的是filemon程序本身用的buffer\r\n他做数据访问跟踪需要用一块内存保存临时数据，如果buffer不够会出现buffer回绕，收集的数据不准确，所以要增大buffer, filemon -T参数带的\r\n\r\nhttp://www.unet.univie.ac.at/aix/cmds/aixcmds2/filemon.htm\r\n\r\n我明天仔细看看你的blog，没有争论谁对谁错，或者必须选择什么方案、技术的意思，只是觉得这个case很典型，可以深入研究一下。既然你们已经在数据库层做到极致，剩下的也只能在操作系统和存储上想办法了。当然，我知道如果能在越高层解决，效果越好。 [/B]

\r\n\r\n我没有用过这个命令来收集统计数据，所以也不知道，呵呵\r\n不好意思\r\n\r\n所以，在使用前，我要先在其它环境上测试。\r\n\r\n\r\n不过，根据我们从其它地方看到的分析数据，等待的确是发生在存储上，而不是在主机上，或是是SAN环境上。

orian

存储是瓶颈我绝对相信，如果我认为楼上两位都看不出来这个。。。。大概我就不用在这混了。哈哈\r\n\r\nfilemon是很好用的东西，而且经过操作系统的一些过滤，从数据库甚至设备层看到的读写不一定对应了LUN的读写，有时候从数据库stat看到的磁盘io不一定和操作系统发送给磁盘系统的io完全对应，filemon可以看得比较清楚，包括lv （对应你们那边就是表空间）和磁盘真正的物理操作情况。是个承上启下的东西，到了存储自身，又屏蔽掉了数据来源，很难看出访问到底是对那个表空间操作了，所以从操作系统做个对应，还是很有用，可以把数据链路真正贯通。你那边有数据库的信息，中间有操作系统的，下面有磁盘的，这条路上到底发生了什么，才能真正理解清楚。

biti_rainy

最初由 orian 发布\r\n[B]存储是瓶颈我绝对相信，如果我认为楼上两位都看不出来这个。。。。大概我就不用在这混了。哈哈\r\n\r\nfilemon是很好用的东西，而且经过操作系统的一些过滤，从数据库甚至设备层看到的读写不一定对应了LUN的读写，有时候从数据库stat看到的磁盘io不一定和操作系统发送给磁盘系统的io完全对应，filemon可以看得比较清楚，包括lv （对应你们那边就是表空间）和磁盘真正的物理操作情况。是个承上启下的东西，到了存储自身，又屏蔽掉了数据来源，很难看出访问到底是对那个表空间操作了，所以从操作系统做个对应，还是很有用，可以把数据链路真正贯通。你那边有数据库的信息，中间有操作系统的，下面有磁盘的，这条路上到底发生了什么，才能真正理解清楚。 [/B]

\r\n\r\n\r\nfilemon report 的数据更详尽一些。\r\n\r\n我们都是使用的 raw  device ，一个数据文件就是一个lv ，那么实际在数据库上看到的数据文件io 和响应时间(假定AIO实际影响不大)基本和 OS 一致。  其实piner也观察到，数据库上看到的 io 和响应时间，跟 存储端观察到的数据，基本保持规律上的一致。\r\n\r\n而在os上我们经常通过 topas  查看 cpu / disk 的状况，piner的系统我没去观察过这个，但在我这边的系统上，hdisk 的busy程度都是差不多的。\r\n\r\nDisk    Busy%     KBPS     TPS KB-Read KB-Writ\r\nhdisk109 23.9    439.4    54.4   387.4    51.9\r\nhdisk53  22.4    399.4    49.9   351.5    47.9\r\nhdisk149 22.4    479.3    59.9   363.5   115.8\r\nhdisk59  21.9    411.4    50.9   323.5    87.9\r\nhdisk13  21.4    411.4    52.4   323.5    87.9\r\nhdisk154 21.4    395.4    49.9   359.5    35.9\r\nhdisk12  21.4    399.4    49.9   307.6    91.9\r\nhdisk151 21.4    399.4    49.9   355.5    43.9

cobalt

讨论的很热烈，差点忘记来看看了。\r\n就hds的建议来看，通常就是他们的主要策略之一。\r\n目的无非是防止多系统之间的干扰，而实际上这需要从管理或者规划上去避免。现实中，我们这也有这个现象，一个项目的磁盘跨越了所有的存储，当这个项目非常busy的时候，其他项目的响应时间很快就上去了，造成其他系统对外服务质量降低。\r\n\r\nhds还常提议，单个系统尽量在已分配的的PG里面纵向做条带，条带宽度不要太大等等。\r\n对大存储来说，如果上面太多混合型的应用，的确很难去做tuning。piner的应用类型还算单一，可能hds的规则二有一些效果。\r\n另外，如果能把目前的环境完整的clone到emc的上面，相信性能不会有多大的差距。两家的架构差距不大，而emc调整的难度更大一些，也难协调一些。\r\n\r\n从我们目前的hds/emc的存储使用情况来看，性能上差距不大，关键还是了解各家存储特性，根据一定的规则做出所谓的最佳实践。\r\n有时候，必要的牺牲还是需要的，以空间换性能。

piner

最初由 cobalt 发布\r\n[B]讨论的很热烈，差点忘记来看看了。\r\n就hds的建议来看，通常就是他们的主要策略之一。\r\n目的无非是防止多系统之间的干扰，而实际上这需要从管理或者规划上去避免。现实中，我们这也有这个现象，一个项目的磁盘跨越了所有的存储，当这个项目非常busy的时候，其他项目的响应时间很快就上去了，造成其他系统对外服务质量降低。\r\n\r\nhds还常提议，单个系统尽量在已分配的的PG里面纵向做条带，条带宽度不要太大等等。\r\n对大存储来说，如果上面太多混合型的应用，的确很难去做tuning。piner的应用类型还算单一，可能hds的规则二有一些效果。\r\n另外，如果能把目前的环境完整的clone到emc的上面，相信性能不会有多大的差距。两家的架构差距不大，而emc调整的难度更大一些，也难协调一些。\r\n\r\n从我们目前的hds/emc的存储使用情况来看，性能上差距不大，关键还是了解各家存储特性，根据一定的规则做出所谓的最佳实践。\r\n有时候，必要的牺牲还是需要的，以空间换性能。 [/B]

\r\n\r\n我在北京测试的时候，emc的表现比hds是要好很多的\r\nhds需要调整的东西太多，而且有的时候没有效果。\r\n\r\n比如，在我的case中，它的压力与响应时间不是线性的，这个就很讨厌。\r\n\r\n我在测试emc的时候，基本是可以达到线性关系的。

cobalt

测试的数据量很小吧。\r\nemc新的dmx-3去年底才到的，配置也一般。能否代表真正的生产环境压力？\r\n如果说真有这个差距，那就是说明cache的算法有了优劣之分。\r\nemc呢，则喜欢事先把这些框框架架先定好了，之后不太建议进行调整。\r\nbiti现在使用的dmx-3能给piner的项目提供性能测试结果吗？哈。\r\n挺想知道同一环境下两者的差距。

piner

我们今年也会上一台的，到时候对比看看

orian

Disk Busy% KBPS TPS KB-Read KB-Writ\r\nhdisk109 23.9 439.4 54.4 387.4 51.9\r\nhdisk53 22.4 399.4 49.9 351.5 47.9\r\nhdisk149 22.4 479.3 59.9 363.5 115.8\r\nhdisk59 21.9 411.4 50.9 323.5 87.9\r\nhdisk13 21.4 411.4 52.4 323.5 87.9\r\nhdisk154 21.4 395.4 49.9 359.5 35.9\r\nhdisk12 21.4 399.4 49.9 307.6 91.9\r\nhdisk151 21.4 399.4 49.9 355.5 43.9\r\n\r\n我们先看看这一点数据，read/write 大概7-8 : 1 而且通常只要数据量不是非常大，我们不需要考虑些操作。那对于读来说，我不知道总计有多少个LUN，按照现在看到的数据，假设对这个系统有160个hdisk, ，4条通路，假设40个LUN，如果每个hdisk平均400KB/s的读，那一秒钟对这个系统大概只有48MB/s，这实在是个小数目。看来问题最主要的还在于：每次io块比较小，数据非常离散，可以说不可能cache命中，必须磁盘读。TPS一个hdisk 50，160个总计8000，你有3个系统，大概一个8000也差不多。\r\n\r\n如果这种情况，降低数据的离散读，使数据更可能从一块连续的空间拿到，效果会更好。这也就是确保每次磁盘读，所有的数据都在失效前被访问。如果磁盘数据过于分散，相邻的数据一定不是自己要用的，因为都可能是另外一个系统的，所以HDS提出的适当集中分布，对于他们的存储特性以及你们的这种环境，可能还真是一个最好的方案。\r\n\r\n另一种办法就是看看能否加大Oracle直接磁盘读的io size，当然，数据库已经在跑，没有办法改变了，但在新的系统、测试的时候，可以考虑一下。例如达到64K甚至更大。不过这样也会因此影响到数据库的性能。到底会不会有效果，可以参考一下filemon, trace的输出，看看其中平均seek是多大，如果平均seek已经超过磁盘总计的LBA/10，随机性就太大了，如果数据能集中一点，磁头少走几道，也是几十ms啊！\r\n\r\n如你们讨论过，critical系统动动危险太大，现在这个情况，这个系统当然不建议有什么大改动了，下次测试或者规划的时候再参考吧。

biti_rainy

最初由 cobalt 发布\r\n[B]测试的数据量很小吧。\r\nemc新的dmx-3去年底才到的，配置也一般。能否代表真正的生产环境压力？\r\n如果说真有这个差距，那就是说明cache的算法有了优劣之分。\r\nemc呢，则喜欢事先把这些框框架架先定好了，之后不太建议进行调整。\r\nbiti现在使用的dmx-3能给piner的项目提供性能测试结果吗？哈。\r\n挺想知道同一环境下两者的差距。 [/B]

\r\n\r\n我的是新整合的几套系统，不具备参考价值。他的不一样，是完全一样的数据库直接拷贝数据文件过去的，应用和数据文件完全没变，只是主机的内存大小有一些变化吧，几乎是真正的完全的存储系统的对比。\r\n\r\n所以期待7月份piner的对比结果  

biti_rainy

最初由 orian 发布\r\n[B]Disk Busy% KBPS TPS KB-Read KB-Writ\r\nhdisk109 23.9 439.4 54.4 387.4 51.9\r\nhdisk53 22.4 399.4 49.9 351.5 47.9\r\nhdisk149 22.4 479.3 59.9 363.5 115.8\r\nhdisk59 21.9 411.4 50.9 323.5 87.9\r\nhdisk13 21.4 411.4 52.4 323.5 87.9\r\nhdisk154 21.4 395.4 49.9 359.5 35.9\r\nhdisk12 21.4 399.4 49.9 307.6 91.9\r\nhdisk151 21.4 399.4 49.9 355.5 43.9\r\n\r\n我们先看看这一点数据，read/write 大概7-8 : 1 而且通常只要数据量不是非常大，我们不需要考虑些操作。那对于读来说，我不知道总计有多少个LUN，按照现在看到的数据，假设对这个系统有160个hdisk, ，4条通路，假设40个LUN，如果每个hdisk平均400KB/s的读，那一秒钟对这个系统大概只有48MB/s，这实在是个小数目。看来问题最主要的还在于：每次io块比较小，数据非常离散，可以说不可能cache命中，必须磁盘读。TPS一个hdisk 50，160个总计8000，你有3个系统，大概一个8000也差不多。\r\n\r\n如果这种情况，降低数据的离散读，使数据更可能从一块连续的空间拿到，效果会更好。这也就是确保每次磁盘读，所有的数据都在失效前被访问。如果磁盘数据过于分散，相邻的数据一定不是自己要用的，因为都可能是另外一个系统的，所以HDS提出的适当集中分布，对于他们的存储特性以及你们的这种环境，可能还真是一个最好的方案。\r\n\r\n另一种办法就是看看能否加大Oracle直接磁盘读的io size，当然，数据库已经在跑，没有办法改变了，但在新的系统、测试的时候，可以考虑一下。例如达到64K甚至更大。不过这样也会因此影响到数据库的性能。到底会不会有效果，可以参考一下filemon, trace的输出，看看其中平均seek是多大，如果平均seek已经超过磁盘总计的LBA/10，随机性就太大了，如果数据能集中一点，磁头少走几道，也是几十ms啊！\r\n\r\n如你们讨论过，critical系统动动危险太大，现在这个情况，这个系统当然不建议有什么大改动了，下次测试或者规划的时候再参考吧。 [/B]

\r\n\r\n\r\nsorry ,这是我这边看到的一套系统，不是piner的，他的压力高多了。 我看到的这个io 在10几 ms 呢。