存储性能测试经验分享

《存储性能测试经验分享》由会员分享，可在线阅读，更多相关《存储性能测试经验分享（7页珍藏版）》请在金锄头文库上搜索。

1、 存储性能测试经验 一、性能测试的目的1、发现性能的瓶颈，并且帮助开发一起优化性能（而不仅仅是发现问题），让性能在当前架构上达到最优；2、 指导选型和最佳实践，给客户推荐最好的方案；因为过程中我们在测试不同的业务模型和配置时候得出来的性能指标可能是不一样的；比如：cdp的io和备份的存储位置分别在那里的时候，性能会更好，这个就是我们推荐给客户的方案了3、产品中关于性能的注意事项和坑，以及碰到这些情况我们怎么解决；比如：cdp的缓冲区是2G，但是后台是可配的，如果发现客户那里cdp因为缓存区满了经常失效，那么我们就可以在当前条件下修改缓冲区（如果不可配的话是不是就是bug了）；二、对于自己的意义

2、1、熟悉整个产品的架构，并且清楚整个产品的瓶颈在哪里，后面甚至能够提出自己的优化建议 -个人觉得性能测试专家是离测试架构师很近的一个岗位；2、对用户场景、部署方案和最佳实践会比较清楚，能够站在更高的角度来看待产品的问题 -做正确的事情（不仅仅只关注自己的一亩三分地），让自己的工作更加有意义；三、性能测试前的准备（磨刀不误砍柴工）1、了解性能的一些基本知识，这个在后面的测试中会非常需要；比如：下面的这些知识自己应该要比较清楚吧（不清楚的可以回去在网上查下）；否则后面在出现问题的时候自己排查和定位的难度会增加很多；而且容易漏掉一些问题 iops和吞吐之间的关系 4K、8K、64K，1M等块大小与性

3、能（iops和吞吐）之间的关系 tpm和tps分别是指什么？Oltp模型和olap模型是指什么 sata盘性能极限是多少？7200转和10000转的性能相差多少？（随机读写，顺序读写） sas盘性能极限是多少？（随机读写，顺序读写） ssd的性能极限是多少？（随机读写，顺序读写） pcie-ssd性能极限是多少？（随机读写，顺序读写） 什么是条带技术，条带技术对性能的作用是什么？ 分层相关的知识（在整个HCI的性能中，分层是起到关键作用的，所以一定要看看，至少在发现问题的时候能够知道是分层引起的） .2、明确需求和场景，并且分析和确定是否合理，同时跟干系人确认对于HCI来说，主场景的重要性就不

4、言而喻了；在测试前提前明确需求和主场景有利于我们更好的做正确的事情，所谓需求和场景大概就是搞清楚下面的几个问题：这个功能给客户带来的核心价值是什么？客户最关注什么？比如：CDP就是保护客户的核心业务的数据和业务连续性（RPO和RTO），对于客户来说，应该就是我购买了cdp后，我的业务真正的得到这些的保护了，而不是有其他的附加条件（标准化交付）。那么，CDP的灾备演练就是客户很关注的，怎样证明cdp的可靠性呢？客户使用的整个过程是怎样的，每个过程客户关注的是什么？比如：客户当前的硬件和部署情况是怎样的（外置存储、超融合的空间，网络等），用我们的CDP功能是否有障碍（io日志和备份分别放在哪里）？

5、过程中客户会怎么配置，我们给客户推荐的方案是怎样的？以上两个问题看起来很简单，实际上会有很多细节性的东西在里面，如果不弄清楚并且跟干系人达成一致的话，可能会导致测试结果想干干系人不认可（不断的让你测试不同情况下的性能指标情况，你又没有足够的理由拒绝，就是因为前期没有达成一致）；3、 确定测试模型，并且跟干系人达成一致（tpm、吞吐、iops等）；对于性能测试来说，不同的测试模型能够得出千差万别的结果；所以需要在测试前就将性能测试模型定下来，并且后面就以这个测试模型为标准，比如：CDP最开始的性能指标依据是400个会话，跑10W tpm（60MB的写吞吐），后面发现cdp的性能不行（CDP的需求

6、是支持30MB），然后再去调查了客户的业务情况，发现大部分的客户业务性能确实是在30MB以下的，所以将性能模型又调整到5W tpm（30MB的写吞吐）了，后面一直用这个测试模型，而且在这个模型下面发现的所有性能问题都要查；也为后面的性能测试模型定下了标准4、根据测试模型固化环境，保证测试环境不要成为瓶颈；性能模型定下来后，剩余的就是根据性能测试模型来固化性能环境了，包括硬件，网络，内存，磁盘大小等等（磁盘最后是留几个空盘位，方便扩容空间），测试cdp的时候就是因为磁盘的大小都是1T，经常导致磁盘空间不足的情况；但是大家都知道，初始化性能环境是一件很麻烦的事情，而且极有可能导致性能环境被破坏了（

7、CDP的性能环境就是因为一直因为有bug要查，所以不敢破坏）；四、性能测试和性能分析1、根据优先级来执行性能测试计划，过程中得出来的每个数据都要确保合理性 其实，性能测试的每个数据都应该是有依据的，除了测试中的误差外；这个就是要求我们前面对那些性能的基础知识比较熟悉了；比如：官方宣称的intel3510 480G的ssd顺序读取高达500MB /秒，写入可达440MB /秒，随机读取高达68,000 IOPS，随机写入IOPS 16000，那么如果我们的业务块大小是4K或者是8K的话，吞吐和iops能够跑到的极限是多少大概就比较清楚了，那么我们测试出来的数据跟极限的差距都消耗在哪里呢？而我们测

8、试的过程中就需要问清楚为什么是这个值，是否正常（很多时候我们得出一个数据，发现跟需求差不多就觉得ok了，其实是不够的），同时这个过程能够让自己对产品更加熟悉的；比如：在用oracle模型来测试io日志合并的时候，发现合并的吞吐只能跑到12MB左右，开发给出的结论是就只能跑到这么多，那么为什么只能够跑到这么多呢？过程中就分别从合并的块大小，读取备份存储的性能瓶颈，读取io日志的性能瓶颈，写入io日志的性能瓶颈等等各个维度进行了分析；最后的结论是在8K的块大小下面就是只能跑到12MB，后面就将oracle的块大小调到了32K，能够跑到48MB；说明确实是跟块大小有关系；2、发现性能的问题后，跟开发

9、一起去分析原因，并且尽量配合开发排除一些其他的因素，帮助开发更好的定位到问题； 发现问题后，千万不要发现问题丢给开发就不管了，这样的话仅仅是一个性能测试执行人员；而是要先将自己的一些分析和排查结果发给开发，让开发参考（最好是能够大概定位到哪个模块，然后找到对应的开发责任人，比如：分层满了，外置存储性能达到瓶颈等等）；这样除了能够帮助开发节省时间外，还能够让自己更好的把握这个产品的性能瓶颈一般在哪些地方，后面就能够自己快速的定位到问题了，同时也能够更好的得到开发的认可；3、测试报告要尽可能的详细，将每个数据都能够给出解释，避免别人问为什么是这个结果的时候答不上来（跟开发一起配合）；相信测试过性能

10、的同学都有类似的经验，经常会碰到有人对自己的测试结果有疑问，然后自己还解释不上来，这个其实还是有点尴尬的；所以，最好是在得到一个结果后，自己就能够搞清楚为啥是这个结果，知其然，并且知其所以然；下面跟大家一起分享下一些影响性能的因素，大家在排查问题的时候也可以参考下；五、影响性能的因素1、vs的数据和io压力分布是否均匀这个在多个虚拟机或者多个虚拟磁盘的时候体现的比较明显，拿oracle的测试模型来举例：一个主机配置了2块480G的ssd；oracle 的虚拟机配置了8个虚拟磁盘，如果8个虚拟磁盘的io压力能够均匀分布到2块ssd上面的话，性能就会更好一点了；同样的，如果多个虚拟机的io压力都落

11、到一个ssd上面，肯定会导致性能比较差；Ps：ssd是跟机械盘绑定到一起的，所以只有让不同的虚拟机或者虚拟磁盘分布到不同的磁盘上面，才能够更好的利用到ssd的性能2、调试开关关闭 这个就不用说， 做性能测试一定要记住将调试开关关闭掉；3、命中率的情况 如果ssd的命中率比较低的话，就会导致大量的io直接从机械盘来读， 性能肯定就比较差了；4、机械盘的io压力 机械盘的随机读写性能都是比较差的，很容易就利用率达到100%了5、各个硬件的极限 如果用到外置存储或者iscsi的话，我们在测试的过程中就需要去查看各个硬件的io压力情况，看看是哪个硬件的io达到瓶颈了，方便去定位问题 6、多个业务之间i

12、o的竞争和抢占 因为当前我们没有做qos，所以在同时并发多个业务的时候，很容易出现io的抢占情况；比如：多个虚拟机同时跑性能的时候，发现性能很难跑上去，因为都在抢占分层的资源；互相淘汰；7、业务自己的性能瓶颈（日志的切换导致性能抖动） 有的时候，我们发现底层的压力并不高，但是性能却一直上不去，很有可能的原因就是业务本身的性能出现问题了，在测试oracle的tpm的时候经常发现会有性能的抖动，这个时候可能就是因为日志的切换导致，所以一个方法就是尽量减少日志的切换（加大日志空间和日志文件数量）8、不同的块大小的性能差异（业务模型很重要）有的时候发现在跑一个业务的时候性能可以，但是换了一个业务模型性

13、能就变差了，可能原因就是因为不同的业务模型的块大小不一样导致，这个可以在后台看到当前业务的块大小是多少；9、网络的瓶颈在分布式系统中除了io的瓶颈外，剩余的就是网络瓶颈了，特别是在千兆环境下面，这个也要作为排查的一个思路；10、其他后台业务的影响（数据修复或者平衡，分层数据回刷等）经常我们测试的过程中本来好好的，但是突然出现性能下降的问题，这个时候很可能是后台的一些行为影响了当前的性能结果，这个时候就需要查看后台相关的日志来排查了；11、程序自己的性能问题如果发现其他的都没有成为瓶颈（比如：硬件极限是100MB，结果只能跑到60MB），这个时候可能损耗就在程序本身了，然后就跟开发一起进一步去定

14、位具体的性能消耗在哪里（一般都是有日志能够跟踪的），比如：最开始io日志的合并速度只有4.4MB/s，这个明显就是程序需要进行优化的（所有硬件的瓶颈都不可能这么低）；六、性能问题排查的经验（现在来看，一般的问题都在io上面，所以cpu和内存的就不在这里介绍了，排查方式也很简单，看看占用率就可以了）1、查看磁盘（存储资源）当前的的io压力情况iostat -x 2|grep -v dm 这个算是最常用的方法了（可以看到各个盘的io压力情况，包括ssd和机械盘的），像下面机械盘的利用率达到100%了，肯定就出现性能暴跌的现象（我们就要分析是否合理了）；同理，如果要测试备份的话，那么备份端目的存储的

15、io压力也要去观察，这样才能够知道瓶颈在哪；2、查看分层空间的使用情况我们可以用过vs_tier_cli -c dump来查看当前分层的使用情况，主要关注model字段，如果是free的话，说明分层的压力不高，如果是high的话，就说明比较高了（这个时候会开始影响性能了）；3、 查看虚拟机当前的缓存命中率情况如果缓存命中率低同时大量读写机械磁盘的话（见上面的图），性能也会上不去；查看缓存命中率的方法：通过 vs_cluster_cmd.sh g vm-disk-1.qcow2 得到对应虚拟磁盘的gfid然后执行vs_tier_cli.py -c dump -a inode，找到对应的虚拟磁盘就能够看到命中率了；4、查看虚拟机磁盘的分布是否均匀（多个磁盘的情况下）假设oracle有8个虚拟磁盘，如果6个磁盘分布到1个ssd，另外2个磁盘分布另外一个ssd，就会导致因为虚拟磁盘分布不均