【专家问答第十期】Symmetrix的性能监控和分析

今天是五一国际劳动节，上海的天气睛空万里有云。我在上海出差，干完活到酒店已经快晚上12点了。上网看看邮件，发两个贴子。早上到客户机房，完成上一天余下的工作，和友商的工程师一起吃了午饭，下午把今天其余的工作都做完。

啊！多么愉快而有意义的五一国际劳动节啊！

不是线程数的原因。客户找我们分析之前，自己已经在主机上想了很多办法了，估计IO的并发性等等他们已经检查过了。

如果在Symmetrix 上使用SSD，一般是做Raid-5 (3+1) 或 7+1，还需要至少一块备盘。

SSD盘最适合的IO是Random Reads，对于数据库来说，一般来说，把索引文件、控制文件，以及客户自己觉得经常去读的一些客户数据，例如参数文件、机构代码等等放到SSD上，就可以取得很不错的效果。

日志文件一般是顺序、大量的写操作，应该把它们分散在更多的物理硬盘上，由于存储有Cache，SSD上存放日志文件没有性能优势。

如果存储是VMAX，那么建议使用FAST VP技术，存储自己会分析客户应用IO情况，可以自动把最合适的数据搬到SSD盘上。

本年度最幽默专家

遭到Yanhong的表扬，汗颜啊，我居然也被划入幽默的专家的行列了，能与提出“自行车是城市污染主因”等言论的幽默的专家们为伍，我感觉良好。

还是写一下与IO类型相关的东西吧，建议大家先学习一下这个贴子：正确描述IO类型

我再谈谈我的看法：

主机上的性能工具一般主要关注在CPU，内存，Paging (or Swap)， IOPS，IO平均响应时间等等方面，对于IO平均响应时间，一般的主机并没有区分读IO和写IO。

存储上专注于IO的监控，看得更细，从存储的角度讲，分析IO，至少要注意到以下几点：

1，读/写：“正确描述IO类型”一文中指出，由于Raid保护的关系，“写通常需要比读更多的资源”，这是对的，但是忽略了另一点，由于现代存储阵列都有缓存，写IO的响应时间往往比读IO的响应时间小。即使Cache算法再好，也无法避免Read Miss，因此，负载较轻时，Random Read的平均响应时间一般在几毫秒级，而写IO的响应时间一般在零点几毫秒级，随机读和写IO的响应时间往往相差十几倍。看到这里，大家应该明白案例一的原因了吧？

另外，存储后端（即磁盘控制部分）对于写IO更容易做优化。Read hit的响应时间与write的响应时间差不多，都是在Cache中完成。我们重点看一下Read miss。大家都有网购的经历吧？我们拿快递公司来类比吧，那么读磁盘是收件，写磁盘是派送。这个收件(read miss)是要求快递公司立即响应的，因此我们一打电话要求快递公司收件，快递员就必须马上上门来取件。而派件（write）时，快递员可以在他空闲的时候派件，还可以把同一小区的快递都带上，把整个小区的货品一次派完，即存储后端在写磁盘时，会尽量把相邻磁道的数据集中在一起写入磁盘。

2，随机/顺序IO，这一点在“正确描述IO类型”一文中写得很好，我这里要补充的是，一般OLTP系统的IO都是随机的小IO，而数据仓库、数据挖掘、备份/恢复、归档、流媒体等等应用的IO是大的顺序IO。OLTP系统要求的是IOPS，数据仓库等应用一般要求的是吞吐量（MB/s）。

综合以上两点，随机读未命中（Random Read Miss）是所有IO的短板，是所有IO中响应时间最差的，而这正是闪存盘（SSD or Flash Drive）的用武之地，

3,IO Size：“正确描述IO类型”一文中写到：“许多存储系统处理大I/O会更快速一些”。然而实际上正相反，几乎所有的存储处理小IO都会更快速一些。它这里漏了一个条件，结果产生了误导，应该写成“对于相同的数据量（MB），许多存储系统处理大I/O会更快速一些”。

4，IO的并发度。前面的贴子中提到过，dd测试无法真正测出存储在实际工作中的性能表现，主要原因是dd无法产生足够多的并发IO。降低IO之间的依赖关系，提高IO的并发度，一直是现代计算机系统努力的目标。例如，现代的数据库系统在读写一个记录时，不会锁住整个表，而是仅仅锁住那条记录，这样其它的事务才可以同时并发地访问其它的记录。存储也是如此，在没有达到存储的性能瓶颈之前，并发数越多，存储可以完成的IOPS也越大。

在实施同步容灾项目时，为了满足客户应用IOPS的需要，就要保证足够的并发度，可以通过增加光纤端口的数量，增加Volume数来增加并发度。实施同步容灾时，由于每个写IO都要写到容灾端，这个IO才算完成，因此每个写IO的响应时间都会加长，这个延时是无法避免的，是容灾必须要付出的代价。只要在客户要求的时间里，完成所有的IOPS，那么这个系统就是符合要求的。还是拿快递公司举例，无容灾的存储相当于负责上海本地业务的快递公司，实施同步容灾后的存储，相当于这个快递公司业务需要覆盖江浙沪。虽然每送一次送货的平均时间延长了，但是如果有足够多的快递员（相当于足够多的并发IO），还是可以在客户要求的时间内把货品及时送到的。

5，Cache的情况。命中率对性能的影响不言自明，还有一点要注意的就是写Cache的容量，对于Symmetrix来说，就是Write Pending的数量，前面也讲过，Write Pending  就是主机写入存储缓存、存储还没有真正写入物理硬盘的数据。Symmetrix系统有一个Write Pending Limit，即缓存中最多可以容纳的数据量。如果存储达到Write Pending Limit，那么一方面会降低读命中率，一方面会使得存储后端无法从容地做写磁盘的优化，存储后端会忙于写磁盘，导致存储工作效率下降。就像快递公司需要派送的货品积压太多，就要爆仓了，还有货品源源不断地进来，为了尽快给新进的货品腾出空间，逼迫快递员随手拿起一件货品就跑去送货…… 因此，应该尽量使存储系统的Write pending数量维持在较低的水平，为了保证这一点，仅仅加大Cache容量是不够的，还要保证有足够的后端性能，就像仅仅加大快递公司的仓库是不行的，还要加快送货的速度。

好吧，今天是跟快递公司较上劲了，看来如果将来IT业不景气了，大家还可以去干快递。

     前辈真是太厉害啦

     不过如果是Oracle数据库，存放索引数据的datafile和存放表数据的datafile没有区别。

由于Oracle在创建table和index的时候只要指定tablespace的名字就可以啦，DBA是不用关心这个tablespace下面的datafile怎么分布。如果在一开始架构Oracle数据库时候，由于DBA不服责任，没有把在逻辑上可能经常使用的一些table和index放置到单独的tablespace中，那么仅从系统和存储层面上做优化还是不能达到性能极致吧。

      您说的日志文件应该是redo log file，其关系到Oracle数据库的性能指标之一。在进行DML操作时候，如果日志文件写的不够快，那么数据库中会有“log file sync”这样的等待事件。但是把所有的redo log都放入SSD实在太浪费，所以您说的“ 有一个卷在白天始终维持着约 400 writes/sec 左右的IO量” 可能就是客户用于存放redo log的卷吧。

谢谢。那通用资料，专家有什么推荐啊。基础且系统的，分享一下。我想很多网友会感兴趣的。

hi, james  还没解密案例二 客户iops上不去的原因是什么？

做为自学，可以先在网上找一些有关性能分析的文章来看（建议找英文资料，系统性更好一些），其实性能分析需要的基本知识非常少，例如前面提到的IO类型，性能指标 (主要是IOPS，Thoughput, Response time 等) 等等，然后具体产品的性能分析就要使用特殊的工具软件。

每个厂家都会有一些性能分析的课程，如果工作确实需要，可以报名去学一下，这些课程在前面也会讲一些基本知识，然后再讲针对具体产品的工具软件的使用方法。

EMC对外公开的资料很少，但是你可以找一找其它厂商的网站，例如服务器厂商或数据库厂商，都会找到一些很好的资料。

再有，可以利用一些搜索引擎，例如，百度一下"DMX-4 Oracle"就可以得到一篇很好的文档。

个人觉得学习最好的办法就是办干办学，如果对这方面感兴趣，向自己的老板多申请这方面的工作来干，相信老板都愿意培养技术人员的。刚开始时有问题多问问有经验的人，干得多了自然就能积累经验了。

想给大家多一点思考的时间，所以迟迟没有公布答案。

关于案例二，我当时是这样分析的，这个卷长时间有400 writes/sec 左右的IO，但是硬盘并不忙，Write Pending也不高，只能是一个原因，就是这每秒400个左右的写IO都写在这个卷很少数的磁道上，甚至可能只是反复写在一个磁道上。

我把我的推测告诉客户，存储上的性能分析也只能帮到这儿了。

2周的专家问答就要结束了，James的谜底留到了最后，我想很多人还意犹未尽。感谢三位专家们的精彩回答。希望专家平时有空多来论坛转转。论坛因你而精彩！

Hi, james  赶在没散场还想再追问几个问题： 通常device/disk driver/DA卡的每秒io数分别达到多少，我们认为比较繁忙？ 磁盘的读写响应时间达到多少毫秒认为比较繁忙？ 内存的write pending占到wp limit的百分之多少算是比较繁忙？

   谢谢

没关系，不急不急，即使这个问答活动结束，再有什么问题还是可以在这个论坛里发新贴提问的。

首先，对于性能的要求完全取决于客户应用的需求。有的应用在IO响应时间在几十毫秒时还可以接受，而以前一个比较大的客户要求响应时间在几毫秒以内，有的应用要在一台DMX-4上加入100多块SSD才能满足它的要求。对响应时间要求越快，那么存储的繁忙程度就要越低才能达到要求。例如，要求响应时间在6毫秒以内，那么可能存储各部件的繁忙程度不能超过30%，如果要求响应时间在10毫秒，那么存储各部件繁忙程度可能可以达到50% （注：这个数字只是举个例子，并不是实际数值）。

对于物理硬盘，目前公认的经验值是：

                    10k FC盘          15k FC盘            SATA

MB/s               10MB/s          13MB/s              8MB/s

IOPS:               100               150                    50

需要注意的是，这些经验值都是一般情况下的平均值，而且是在不同IO情况下取最先达到的值，例如，在每分钟15000转的光纤盘上，小IO情况下，先达到150 IOPS，但这时的吞吐量可能远没有达到13MB/s。

即使同一块硬盘，外圈磁道的性能可能是内圈磁道的两倍以上。

Symmetrix 内存的write pending应尽可能在50%以下，在IO高峰时短时间的超过50%影响不大。

DA的IOPS限制很难说，不同存储DA的性能不同，而且不同IO情况，DA能承受的IOPS也不同，我一般是看DA上的%busy，虽然有时DA达到90% busy 客户才会感觉有性能问题，但是正常工作时建议不要超过50%。

Device应该是指给主机访问的volume，由于涉及的情况比较复杂，例如Raid-1 还是Raid-6，是否Meta volume，命中率等等，device没有一个限制或是建议值，由于IO最终会落到物理硬盘上，因此做性能规划时只会考虑物理硬盘是否满足性能要求，但是比较通用的建议是每个应用的各个device的IO量尽可能平衡，这样可以避免热点盘的产生。

在这里总结一下谈性能最重要的几个方面：

在最开始我说过，谈性能要考虑多方面的因素，以前我发过一个微博：谈 IOPS 不谈 IO Size 就象数钱只数张数不看面额。

也许还要加一句，谈 IOPS 不谈响应时间就象谈工资只讲数字，不讲是月薪还是周薪。当然，还要考虑读/写的比例，顺序/随机的比例，平均值和峰值的要求等等....

差点儿忘了说最基本的一点，在检查性能之前，一定要先检查整个系统是否兼容，是否健康，有时候，困扰所有人几个月的莫名其妙的问题可能仅仅是因为一根没有插紧的光纤头。

感谢专家指导，对dmx性能方面知识又提高了不少

感谢这两周来大家的积极参与，每次与别人交流，我都能学到一些东西。虽然时间有限，但还是希望这里的讨论能够给我们带来一些思考。我在发贴时要求自己尽量做到客观、准确，但是如有错误之处，还请大家谅解和指教。

感谢 Jason，Cecil 和 Jessie 的帮助。

希望能够在其它的讨论中继续与大家交流。

祝大家健康、开心、顺利！