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

orian

建议filemon先看看，实际的IO是多大，有时候系统并不像想象中那样工作。\r\nlv和pv是不同的，可能是不同的io size\r\n如果数据真的分得这么散，当访问量非常大的时候，确实有可能只有cache那么多的命中率，特别是没有很好的预取和回写算法（参数）的时候。不过这些东西很难调了，还会随系统运行情况变。如果可能，一层一层分析一下，先看数据库的数据访问特性，在分析对应的分区/表空间/逻辑卷情况，最后看看stripe。\r\n\r\n尽管stripe可以最大限度分散数据度，但由于太分散，有时也会引起split io或者不能触发存储预取的情况。当然，没有数据说什么都是猜想。还是拿数据看看。\r\n\r\n一般来说，hds的数据在磁盘上的分配不如其他两个厂商分散，所以stripe还是必要的，但还有一些操作系统相关的东西可能需要关掉。对于stripe size也有两种方式的使用，一种是让db的一个io size=stripe size，这样可以减少总的io操作量，但是可能会触发更大的磁盘读（吞吐量），另一种是db io size=stripe size * stripe width，这样iops虽然更多，但是磁盘读的吞吐量会少，如果读操作非常随机，这种情况会更好一些。如果是后者，显然128k*8的数字就太大了。\r\n\r\n不过也有另外第一种情况的可能，而且操作系统这样就会split io，是很大的cpu负担，你看看如果系统cpu不忙，则这种办法也可能可取。\r\n\r\n艺术，数字家艺术。哈哈

orian

cobalt说的8个path也多了点，4个就足够了，如果可能，分成2-4个path访问一路lun会减少不必要的server cpu负担。我不知道hds的做法，对于ds8000无所谓（几乎没影响），但对于有些厂商，path太多会影响存储内部带宽的。

biti_rainy

1: 一个ldev 没有8个path的，我们都不是将ldev 输出到所有port。 所有ldev 对应都是4个path。\r\n2：数据库 block 8k ，默认最大数据库io  128k，lv  stripe  size  128k。真实情况下数据库大多都是8k io ，数据库上就可以看到。\r\n3： 从数据库及应用层面来看，没有明显的不合理的地方。 因为毕竟是自己的应用、自己规划，而且大家对存储还是有一些认识的。从数据库的角度来说文件的分布，并没有什么好的调整的方法，因为我们对oracle数据库已经是相当地熟悉了，一般不会埋下比较初级的错误。\r\n4：当初规划的时候，厂商也叫上的，现在厂商也不能明确地指出问题在哪里，因为tuning 这东西，根据不同环境而不同。 我们的做法并不是错误。 当然可以尝试别的做法，只是事实上不大可能。厂商也只能不痛不养的提点建议。\r\n5：USP  slot 为 256k ，数据库的io 绝大部分都是8k（根据索引获取数据），尝试过修改存储参数使得当8k  io的时候 存储内部读满 256k（当作预读，但对应用其实意义不大）  以及只读8k 两种设置，但并没有明显变化。所以我们会怀疑 256k的slot 太浪费cache 资源了，64k 更合适。 厂商证实最新出的存储已经恢复到64k  slot。\r\n\r\n6：从数据库上和存储上观察到的io 响应时间很接近，也就是说排除是在os 层面（如cpu 资源不足等）的原因使得  数据库和存储之间io响应差异比较大。 os 上 cpu资源不紧张的。 存储端自身看到的 命中率是 10%多一点。\r\n\r\n\r\n\r\n其实我们现在关心的问题是，如何有效地提高存储的命中率。 存储端  除了 slot size 的变化外，还可以做的看起来就是让被访问的数据更集中以提高命中率（但这是双刃剑，也可能造成磁盘过热）。\r\n\r\n因为我们实际也计算过，应用都是读为主的，17000/(1 - 10%) / 236   。一块盘也就大约分担到80个io。 80 iops 也没有达到磁盘的极限，为什么应用 io 从 17000  iops 到18000iops 就能发生 拐点 的变化。 这应该归结为存储自身有问题。

orian

slot太大是个问题，但hds和emc都是这样，可能和他们没有用一个统一的instance有关，如果动态调整slot大小，在微程序上设计太复杂。ibm是一个大os，动态调整很容易，cache效率方面稍好一些，这些就不提了。\r\n\r\n让数据集中，似乎是一个好办法，至少在slot这么大的情况下。读8k，物理上就要读128k，如果数据太分散，120k的预读实际没有意义，而如果能让数据集中，在120k预读数据命中的可能性就大多了，cache更有效。但还是要看数据库密集读的数据总量有多少，不能和128G cache总量相差数倍，如果是累加只有几十G，1-2百G的表和索引，集中数据看起来会更好。\r\n\r\n至于为什么在16000-17000出现拐点，一个磁盘80个IO，我怀疑在我们计算中有什么地方疏忽，例如hds磁盘的stripe是多少，假设128k，读128k的iops不是通常的240iops/disk，这个是用小io计算的（512或者4k），而会大幅度降低，例如100iops/disk；或者是hds实际并没有并行读镜像的两块盘（可能性不大），等等，还有一些技术细节我不了解hds是如何实现的，所以计算出来80个裸盘io出现拐点的可能性不是没有。\r\n\r\n现在这种情况，如果数据量真的不是非常大，做一下集中，未尝不是个好办法。

biti_rainy

iops 我们都是采用8k 来计算的，因为数据库确实就是8k的io。 当然如果8k 对于厂家宣称的 150 iops 还是偏大的话，那确实是存在这个比较大的偏差。  \r\n\r\n部分数据相对集中看起来是大家都希望去证实的一种方案，只是实际操作上麻烦太多。很难对同一个应用同一个存储去验证两种做法，尤其是一种以验证为目的的做法。因为要实现这个，现在中转的存储空间都需要再去调剂的话，难度增大很多。 \r\n\r\n不过，现在有新的厂家存储到货，将来在线系统切到新的厂家存储上（原来成为一个容灾），我们再看看表现。

piner

哈哈，才看到，不就在讨论我的那破存储吗？\r\n\r\n今天来了几个香港那边的人，又在开始收集日志了，关于我的疑问：\r\n1、现在1个slot 到底等于1个segment还是4个segment，他们的回答是1个，升级微码前是4个，ft，如果这边大的变化，我的命中率能没有一点变化？？？\r\n\r\n2、ldev是否存在资源限制或者队列问题，回答是没有\r\n让他们继续去分析吧，为了这个问题，已经分析了多半年了，再分析下去，估计要分析他们的代码才能找到原因了\r\n\r\n问题的描述，见我的blog\r\nhttp://www.ixdba.com/html/y2007/m04/62-hda-storage-usp.html

piner

关键点有\r\n1、我们的数据库cache本身很大，而且命中率有96%以上，如果数据库层无法命中的数据，对存储层来说，肯定也是很刁钻的数据。\r\n\r\n2、cache的尺寸，其实64K都是偏大的，这点IBM还是好，最小可以只有4K

cobalt

正主也来了，哈哈。\r\n热闹。\r\n下午潜心研究一下，哈。

cobalt

想了想，有个问题觉得还是有必要提一下。\r\nhds提出将数据尽量分布在同一PG内，以提高数据的命中率。hds这个依据是存储有个判断机制，当I/O落到连续的3个track时，它会认为这是一个顺序操作，于是会做prefetch。好像ibm也有这个机制。实际上ibm和hds的专利互换产生了很多类似的技术，哈。\r\n\r\n但biti_rainy说过，前期的规划及数据库设计都没有问题；piner也提到数据库cache很大，在数据库层上命中率也有96%，因此要找的刁钻数据必定需要直接从disk中获取。因此俺觉得仅仅靠存储做prefetch，对cach hit是不会有多大提高的。

orian

要做数据访问模型分析了。。。\r\nILM哈哈