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

cobalt

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

\r\n记得保留几份performance monitor的数据。\r\n如果方便的话，600的配置和新dmx-3的binfile配置将来做一个比较吧，哈。\r\n\r\n都可以用模拟器run一下。哈。\r\n顺便问一下，你们平时用模拟器看现有配置吗？

piner

最初由 cobalt 发布\r\n[B]\r\n记得保留几份performance monitor的数据。\r\n如果方便的话，600的配置和新dmx-3的binfile配置将来做一个比较吧，哈。\r\n\r\n都可以用模拟器run一下。哈。\r\n顺便问一下，你们平时用模拟器看现有配置吗？ [/B]

\r\n\r\n\r\n没有用过什么模拟器，看配置末，都是直接看，文档也记载的有。

piner

要么我今天做个filemon的东西上来，主要是白天压力都不大，晚上压力才大\r\n\r\n而且，现在块51了，压力也小了一些。

biti_rainy

最初由 cobalt 发布\r\n[B]\r\n记得保留几份performance monitor的数据。\r\n如果方便的话，600的配置和新dmx-3的binfile配置将来做一个比较吧，哈。\r\n\r\n都可以用模拟器run一下。哈。\r\n顺便问一下，你们平时用模拟器看现有配置吗？ [/B]

\r\n\r\n在数据库中保留的性能的数据(iops 和 response time等) 应该都是有的。 我这边是保留系统上线2年以来的所有性能数据，每天几个时段定时采集。

cobalt

[QUOTE]最初由 piner 发布\r\n[B]\r\n\r\n\r\n没有用过什么模拟器，看配置末，都是直接看，文档也记载的有。 [/B][/QUOTE\r\nhds/emc都有模拟器，可以将现有配置导进去，方便查看配置。\r\n晚上压力大，是不是晚上过账？]

cobalt

最初由 cobalt 发布\r\n最初由 piner 发布\r\n[B]\r\n\r\n\r\n没有用过什么模拟器，看配置末，都是直接看，文档也记载的有。 [/B]

\r\nhds/emc都有模拟器，可以将现有配置导进去，方便查看配置。\r\n晚上压力大，是不是晚上过账？

piner

最初由 cobalt 发布\r\n[B]\r\nhds/emc都有模拟器，可以将现有配置导进去，方便查看配置。\r\n晚上压力大，是不是晚上过账？ [/B]

\r\n\r\n晚上大家都比较闲啊，买卖东西啊

piner

其实，有的时候，我也认可这么说，但是，证据还是不是太充分的。\r\n\r\n

\r\n\"降低数据的离散读，使数据更可能从一块连续的空间拿到，效果会更好。这也就是确保每次磁盘读，所有的数据都在失效前被访问。如果磁盘数据过于分散，相邻的数据一定不是自己要用的，因为都可能是另外一个系统的，所以HDS提出的适当集中分布\"\r\n

\r\n\r\n我这么说吧\r\n如果三个系统访问一个raid组的iops，与一个系统访问一个raid组的iops相同，使用的空间也相同。那差别出现在哪里？\r\n\r\n你如果说，一个系统访问数据，可能带上别的系统，但是，我也在想，那别的系统如果很随机，也可能会访问该数据。\r\n\r\n也就是说，3个很随机的系统，与一个很随机的系统，访问规则其实是一样的。

orian

访问规则一样，但其实其分配的平均度还是不一样，我们做个假设，3个系统都是完全随机访问。\r\n\r\n1111111111222222222222223333333333333  raid group\r\n1111111111222222222222223333333333333  raid group\r\n1111111111222222222222223333333333333  raid group\r\n1111111111222222222222223333333333333  raid group\r\n1111111111222222222222223333333333333  raid group\r\n1111111111222222222222223333333333333  raid group\r\n1111111111222222222222223333333333333  raid group\r\n1111111111222222222222223333333333333  raid group\r\n\r\n分别表示1/2/3个系统，如果3个系统压力差不多，每次访问落到1，2，3的可能性也都差不多。特别是前后两次。\r\n\r\n1111111111111111111111111111111111111111\r\n1111111111111111111111111111111111111111\r\n1111111111111111111111111111111111111111\r\n2222222222222222222222222222222222222222\r\n2222222222222222222222222222222222222222\r\n2222222222222222222222222222222222222222\r\n3333333333333333333333333333333333333333\r\n3333333333333333333333333333333333333333\r\n3333333333333333333333333333333333333333\r\n\r\n如果随机性一致，假设各个系统十次IO，共计30次read，并且分布很均匀，可能看到的情况是read交替发生，分别对应1,2,3,1,2,3,1,2,3这样的访问，同时假设3个系统的数据量相同。（暂不考虑系统之间差别比较大的情况，我直觉上感觉结果类似），同时假设磁盘全盘寻道时间为15ms（稍慢一点，但快也快不了太多）\r\n\r\n对于方案1，由于raid stripe比较大，io比较小，每次io读一个盘就够了，结果是磁头从1跳转到系统2，平均用5ms,再跳到系统3，还是5ms,回到系统1,又用了10ms，这样30次总计寻道时间约为20*10=200ms，由于有不同的raid group（9个），这30次完成的时间可能存在部分并行，数据分散在9组盘，因此可能性大约是1/9，即总的io时间大约22ms之内完成30次io（由于读一般在1/(2*15000)秒之内完成，一定不超过0.1ms，所以读的时间忽略，只考虑寻道）\r\n\r\n对于方案2，磁头每次io读，寻道时间比较长，一次为7.5 (大约是全盘寻道的一半），完成10次为75ms，但分散在3组raid里，并行度为3，完成30次io大约用25ms。\r\n\r\n从这种方式计算，可以看到最大分散式的磁盘访问效率应当高于集中式的，但差别并不是几倍关系，而是25%（例如）\r\n\r\n如果存在某种系统现住比其他系统忙的情况呢？极端情况为系统1最忙，系统2最不忙，系统3也比较忙，比例大约4:2:4，即30次io中各12次系统1/3，6次系统2\r\n\r\n方案一：\r\n系统1寻道12*(2.5*2/5+5*1/5+10*2/5)=48ms   (12次寻道中，1/5可能磁头在系统2, 2/5可能磁头在系统3，2/5可能就在系统1自身附近）\r\n系统2寻道6*(5*2/5+2.5*1/5+5*2/5)=39ms\r\n系统3寻道48ms 完成\r\n累计时间135ms，并行度依然是9，平均为15ms\r\n\r\n方案二\r\n系统1，12*7.5=90ms，并行度为3，平均为30ms\r\n系统2，6*7.5=45ms, 平均为15ms\r\n系统3，平均为30ms\r\n\r\n从以上计算，似乎得到的结论都是分散优于集聚。不过这里面有一个小漏洞，就是由于3个系统相互独立，我们并不需要3个系统的累加平均，而可能只需要其中一个。意思就是我并不需要3各系统总平均时间最快，而可能只需要1个最快，其他两个可以更慢一些。按照方案1的情况，无论系统1/2/3各自的io量多少，其实都会受到别的系统的影响，这样看来第一种情况下，方案一完成12次io，实际花了135ms（别的系统没有读完，系统1也要等），实际平均为11.5ms的响应时间。而方案二为30/12=2.5ms ! 不要怀疑，整整快了5倍，就是这样的！\r\n\r\n如果这样，我们可以构造一个特别的系统，让其中一个达到最优。显然办法就是让IO量最大的分散在最多的盘上，io量次之的分散在稍少的盘上，大概比例可以按照io量分配，但它们之间没有任何重叠。这里面有比较冗长的计算（过程并不复杂，但要考虑很多概率的问题），在这里就不详细写了，这也就是所谓加权最优，让更多的数据访问在最大的并行度实现，但它们之间不相互干扰。\r\n\r\n这其中还没有考虑很多问题，一个是cache hit的问题，另一个是几个系统之间的高峰、低谷相互重叠，如果把这些东西都加进来，估计没有谁能算得清。而且数据位置、io量还在不停变化，计算结果可能只有理论意义，实践上没有任何用途。\r\n\r\n现在我的结论大概是这样：\r\n1. 如果系统之间io量比较稳定，并且高峰低谷没有明显差异，可以采用集中式（独占raid group)\r\n2. 按io量比例分配磁盘，io量越大，占据越多的raid group，在可能的情况下，避免系统之间raid group的跨越\r\n3. 如果无法避免，例如io量很大，但数据量不大，在没有达到边界值的时候（iops/容量5iops/G），尽力分到更少的盘/raid goup上\r\n4. 如果远远高于这个值，例如达到了10，则尽力分到更多的盘，具体分配规则如下\r\n5. 分配raid group之间的跨越以iops/G为比例，量越多，跨越越多。假如有3个系统，系统1, 20 , 系统2, 10, 系统3要求 5，则系统1跨所有的盘，系统2跨2/3, 系统3跨1/3，系统2和3之间没有重叠。\r\n6. 以上永远的限制条件是保证任何时候，任何系统的任何一块磁盘iops < 200\r\n7. 如果第6条达不到，则需要考虑那个系统不是oltp业务，优先oltp\r\n8. 如果第7条也做不到，say no to everyone，然后采用最简单的方案：把所有数据平均分散在所有的磁盘上。正如搂主所做。\r\n\r\n以上只是一个概念性的经验，并没有严格分析，可能随系统io特性不同而有巨大差别，不是通用的方案。特别是如果系统达到极限的时候，以上计算完全失效。而这个极限，大概就是楼主遇到的17000这个情况。

piner

这个问题，再深入下去就要搞个数学模型来计算了\r\n虽然你上面说的有一定道理，但是，也还是有漏洞的。\r\n\r\n1、3个系统可能访问一个raid组或者是一个磁盘的三个地方，引发寻道等待，那么，一个系统来说，io也是并发的，因为存在多个并发用户与并发处理的sql，而且，我也有很多的数据文件，他们就是集中在一个raid组上，也可能分布的位置跟3个系统的位置一样。\r\n也就是说，在一个系统访问一个raid组，那么，数据分布也可能是\r\naaaaaaaaaabbbbbbbbbbbccccccccccc\r\naaaaaaaaaabbbbbbbbbbbccccccccccc\r\naaaaaaaaaabbbbbbbbbbbccccccccccc\r\n访问的规则，因为很离散，可能就是访问a了就访问c，然后访问b。。。。。。\r\n跟多个系统的差别在哪里？\r\n\r\n2、特定的系统访问特定的raid组，并不能减少iops\r\n如系统1，10个，系统2，10个，系统3，也是10个落在一个raid组上。\r\n那么改成一个系统占有一个raid组\r\n那么可能就是，30个iops，位置也正好可能就是在那3个系统的位置，访问规则可能因为不同的数据文件的问题，访问规则可能就是一样。\r\n\r\n3，其实我最想不明白的是\r\n为什么一个raid组，给3个系统访问，那2个忙的系统就返回很慢，而那个不忙的系统返回就快，命中率是那个不忙的更低。\r\n按照你的理论，因为它受系统1、系统2的影响，响应速度应当一样才是。