zoukankan      html  css  js  c++  java
  • 转:你对存储性能了解多少?

    某医院经过四次IT系统升级改造,系统性能改善并不明显,问题到底出在那里呢?

     

    某医院经过四次IT系统升级改造,系统性能改善并不明显,问题到底出在那里呢?

     

    表1 SPC-1 IOPS测试值超过10万的磁盘阵列

    用户通常对存储存在以下几个错误认识。

    ● 许多磁盘阵列的性能(IOPS)都高于50万。但实际情况是,当今世界还没有SPC-1 IOPS超过50万的磁盘阵列。

    ● 磁盘阵列带宽的成倍提升也会使磁盘阵列的性能(IOPS)相应成比例得到提升。但实际情况是,在OLTP和数据库应用环境下,存储的性能(IOPS)受存储带宽的影响很小。

    ● 磁盘阵列中的Cache在所有情况下都能提升存储性能(IOPS)。但实际情况是,在OLTP和数据库应用环境下,存储的性能(IOPS)受盘阵Cache大小的影响很小。

    ● 数据库中所有的数据都需要高性能(IOPS)。但实际情况是,在多数应用中,只有数据库中的少数数据需要高存储性能(IOPS)。

    4次升级带来的困惑

    由于企业的业务对信息化越来越依赖,用户的业务对应用性能的要求也就越来越高,这使得用户经常要面对IT系统的升级扩容问题。从技术角度看,IT系统的升级改造比建设一个全新的IT系统难度更大,而IT系统的升级多是因为系统的性能无法满足业务的需求而进行的。

    IT系统升级改造失败的例子很多,甚至在最初的IT系统规划期就埋下了导致系统很快就需要改造的种子。

    下面是一个典型的案例。北京某医院因业务部门抱怨HIS系统的响应时间越来越慢,而对HIS系统进行升级改造。

    医院信息中心的相关人员与几个供应商会诊后,确认是硬件指标太低,造成性能太慢。硬件差,简单,只要有资金就可以解决。销售商推荐了更高规格的硬件设备。于是,医院HIS系统采用了新购置的高性能硬件,这就是第一次IT系统升级改造。

    IT系统第一次升级改造,医院购买了高性能指标的服务器和盘阵。

    ● 换服务器:采用某品牌的服务器,CPU从两个增加到4个,主频从1.8 GHz变成3.4,GHz,内存从2GB扩充到4GB。

    ● 换存储设备:SCSI盘阵太慢,换成2Gb光纤盘阵,加上2Gb的光纤交换机,并采用SAN存储架构技术。最终,该医院采用了某品牌的盘阵(双控、7X500GB SATA硬盘,总容量为3.5TB),连同数据备份一并解决。

    这次系统改造价格并不贵,总价在30万元以内,并未超过原来的预算。

    一个月过去了,财务部门反映,采用新设备进行结算,速度和以前差不多。

    硬件已经提升了,有问题只可能是软件了,于是又有了第二次IT系统升级改造——应用软件优化。软件公司也尽了力,但应用性能的改善仍然不明显。

    最后,软件公司找来了一位高人,检测后认为,问题还是出在硬件上,是存储的I/O性能差。于是又有了第三次IT系统升级改造——优化存储的I/O性能。

    硬件厂商的工程师对盘阵上的系统版本进行升级,并打了新的补丁,还是不见效果。后来,硬件厂商的一位高级技术经理表示:“现在用的这个盘阵规格太低,只适合做备份,不适合做OLTP应用,如果使用更高档的全光纤盘阵,应该就没有问题了。”于是有了第四次IT系统升级改造——再次更换磁盘阵列。

    现在是2007年,主流产品都是4Gb的光纤盘阵,于是用户又更换了更高指标的存储设备,总带宽达到16Gb。盘阵的Cache是4GB,硬盘使用了8块300GB的4Gb光纤硬盘。此外,又在服务器上增加了两块4Gb FC HBA卡,服务器的内存也增加到8GB,还更换了4Gb光纤交换机。

    这次升级又投入不少资金,但一个月后业务部门又反映,月底财务结算时,速度仍然和以前一样——客户端的各种操作响应与第一次系统升级改造后的情况差不多。

    经过四次IT系统升级改造,性能改善并不明显,问题到底出在那里呢?

    在很多招标项目中,我们常常看到用户这样设定他们的存储需求:磁盘系统的性能(IOPS) 高于50万;磁盘系统裸容量大于多少TB;存储系统必须通过提供可用的部件冗余设计,如电源、风扇及核心关键模块等,使系统的可靠性达到最高级别;磁盘系统应具有多平台/多主机的连接能力,能满足服务器及应用系统对数据的集中存储和管理要求,同时,可以集中管理和分配存储容量,提高生产效率,并提供对主流集群系统的支持;可通过存储管理软件集中管理,通过Web、控制台、GUI界面等方式对磁盘阵列的各项指标进行管理和调整……

    用户完全按照上述要求招标得到的存储系统,就一定能够满足他们的应用需求吗?我们认为,实际情况并不是这样。

    澄清错误认识

    许多磁盘阵列的性能(IOPS)都高于50万?

    我们经常在各个存储厂商的磁盘阵列产品彩页上看到,这些磁盘阵列产品被标上几十万甚至几百万IOPS的存储性能。这些磁盘阵列在OLTP、数据库应用环境下,真有那么高的性能吗?

    存储系统性能指标IOPS(I/Os Per Second)的大小取决于许多测试参数,如测试数据的类型,是顺序还是随机;测试数据块的大小尺寸;被测存储产品的RAID级别设置;被测存储产品的磁盘数量及转速等。而同样配置规格的磁盘存储系统,在不同标准下测出的IOPS结果也会有天壤之别。100%顺序读的IOPS会比100%随机写的IOPS高25倍以上。

    实际上,许多厂商在其产品彩页上公布的IOPS(高达几百万)是对该产品中的Cache进行100%顺序读的测试结果。对于运行联机事务处理(OLTP)、数据库和E-mail等应用的用户而言,由于应用对数据的访问中,随机I/O占很大比例,因此厂商产品彩页上的IOPS指标对用户选择满足自身应用需求的存储产品没有太大参考价值。

    反映联机事务处理、数据库和E-mail等应用环境下的存储性能指标是SPC-1 IOPS

    SPC的全称是Storage Performance Council(即存储性能理事会)。这是一个非赢利组织,成员由几乎全部的国外存储厂商和部分大学、研究机构组成,其使命是定义、标准化存储系统的基准测试。其SPC-1基准测试很好地模拟了联机事务处理(OLTP)、数据库和E-mail等真实应用环境下存储产品的性能。SPC-1基准测试包含以下三项主要测试指标,即SPC-1 IOPS(Maximum Throughput,每秒输入输出次数的最大值)、SPC-1 LRT(Average Response Time at the low level of demand,平均响应时间)、SPC-1 Price-Performance($/SPC-1 IOPS,每SPC-1 IOPS的价格),用户可以从中了解存储产品在联机事务处理(OLTP)、数据库和E-mail等真实应用环境下的性能和性价比。

    何处可查SPC-1 IOPS测试结果?

    从SPC网站(http://www.storageperformance.org/results/benchmark_results_spc1)上可以查到所有进行SPC-1基准测试的存储产品的SPC-1 IOPS测试结果。每份SPC-1基准测试报告的主要内容如下:SPC和厂商双方对SPC-1测试结果的签字认可;SPC-1测试结果;被测存储系统的详细配置和价格;被测存储系统的测试配置连接图;测试详细记录等。

    各存储厂商增加被测产品SPC-1 IOPS值的办法有两个:尽量使用小容量(如36GB、73GB)、高转速(15krpm)的磁盘,尽量增加被测产品的磁盘数量,因为单块磁盘的容量越小、转速越高,其IOPS值越高,磁盘数量越多,通过RAID 0获得的IOPS值越高;尽量选择RAID 10设置,因为在各种RAID级别中,RAID 10的IOPS值最高。

    当今世界还没有SPC-1 IOPS超过50万的磁盘阵列。除了固态存储外,SPC-1 IOPS测试值超过10万的磁盘阵列只有3个品牌的6种型号(见表1)。

    总结所有的SPC-1基准测试报告,从中得出的结论是:SPC-1 IOPS值随被测存储产品的磁盘数量和转速而线性增长。因此,我们可以估计未进行SPC-1基准测试的高端存储产品的SPC-1 IOPS值。Fujitsu Storage Systems ETERNUS8000 Model 2100(最多可容纳2760块磁盘),其满配置的SPC-1 IOPS估计值=(2760/664)X108745.34=452013.76。EMC DMX-3(最多可容纳1920块FC磁盘),其满配置的SPC-1 IOPS估计值=(1920/512)X123033.40=461375.25。HDS USP V(最多可容纳1152块磁盘),其满配置的SPC-1 IOPS估计值=(1152/512)X123033.40=276825.15。据此我们可以说,当今还没有SPC-1 IOPS超过50万的磁盘阵列。

    下列公式可帮助用户估算其所采购的磁盘阵列的真实性能(SPC-1 IOPS)。所购盘阵的真实性能(SPC-1 IOPS)=[所购磁盘阵列的磁盘转数(rpm)/SCP-1报告中被测磁盘阵列的磁盘转数(rpm)]X[所购磁盘阵列的磁盘数量/SCP-1报告中被测磁盘阵列的磁盘数量]XSPC-1报告中的SPC-1 IOPS值。

    磁盘阵列带宽的成倍提升也会使磁盘阵列的性能(IOPS)相应成比例得到提升。

    以Fujitsu的ETERNUS系列磁盘阵列为例,我们从SPC网站上找到同一型号盘阵的不同接口带宽配置的SPC-1基准测试报告进行比对,得到的结果如表2所示。

    以IBM的DS系列磁盘阵列为例,我们从SPC网站上找到同一型号盘阵的不同接口带宽配置的SPC-1基准测试报告进行比对,得到的结果如表3所示。

    从表中可以看出:带宽的成倍提高,只带来约6%~7%的IOPS性能提升。这说明在OLTP和数据库应用环境下,IOPS受存储带宽的影响很小。在OLTP和数据库应用环境下,提升存储带宽对改善IOPS不明显的原因是木桶原理、短板效应。因为在磁盘阵列这个整体中,磁盘本身的性能是其中“最短的一块板”。

    前文提到的失败案例,就是用户不清楚在OLTP和数据库环境下,磁盘阵列的性能(IOPS)主要取决于磁盘的数量和转速,提升存储带宽对改善IOPS的作用并不大。该用户在几次升级改造中,虽然将存储从SCSI升级到2Gb光纤+JBOD,最后到4Gb光纤+JBOD盘阵,但磁盘数量却从14块18GB 10k rpm盘减到最后的8块300GB 10Krpm盘。因此,在存储硬件这一部分,存储的性能(IOPS)实际上不升反降。如果最初的应用性能不佳是硬件性能不够的判断是正确的,那么后来的几次升级改造虽然提高了服务器的处理能力,但存储的性能(IOPS)并未提高,有这样一块“短板”存在,应用的性能没有改善也就不足为奇了。

    磁盘阵列中的Cache在所有情况下都能提升存储性能(IOPS)?

    以Fujitsu的ETERNUS系列磁盘阵列为例,我们从SPC网站上找到相关不同Cache配置的SPC-1基准测试报告进行比对,得到的结果如表4所示。

    以IBM的DS系列磁盘阵列为例,我们从SPC网站上找到相关不同Cache配置的SPC-1基准测试报告进行比对,得到的结果如表5所示。

    从表中可以看出:磁盘阵列的性能(IOPS)随盘阵的磁盘数量和转速增加而同比例提升;大比例地增加磁盘阵列的Cache,无法获得同比例的性能(IOPS)增加。因此,在OLTP和数据库应用环境下,IOPS受盘阵Cache大小的影响很小。

    在OLTP和数据库应用环境下,增加盘阵的Cache对改善IOPS不明显的原因同样是木桶原理、短板效应。因为在OLTP和数据库应用环境下,盘阵Cache的命中率很低。而在磁盘阵列这个整体中,磁盘本身的性能是其中“最短的一块板”。

    数据库中所有的数据都需要高性能(IOPS)吗?

    几乎所有数据库厂商的性能调整手册或白皮书都告诫用户:需要把数据库的Temp Tables、Tedo Logs等单独存储于由尽量多的物理磁盘组成的逻辑卷上(虽然这些文件都很小)。这说明数据库的这些数据需要较高的存储性能(IOPS),而数据库的其他数据相对而言需要的存储性能(IOPS)较低。数据库厂商已经清楚地告诉了用户,数据库中的数据对存储性能(IOPS)的需求是不同的,并非所有数据都需要高存储性能(IOPS)。

    通常情况下,数据库中只有少部分数据需要高存储性能(IOPS),而大部分数据对存储性能(IOPS)的要求较低。

    在现实应用中,这种情况比比皆是。比如,某省邮政储蓄的综合业务系统负责全省邮政储蓄的一本账、大会计、客户信息管理、综合柜员制等现代商业银行业务的运行。随着业务的发展,该系统日益受到性能问题的困扰。虽然系统经过多次优化,包括将高端存储系统的磁盘数量从不足100块增加到226块,但随着网点、客户数量的增加,以及新业务的开通,系统仍旧受到性能问题的困扰。通过对运行综合业务系统的生产服务器一整天的CPU利用率历史记录进行分析,到出了如下结论:用户综合业务系统的服务器CPU数量和运算能力基本可以满足业务需求,应用性能差的原因不是CPU运算能力不足或数量不够,而是CPU的处理能力被I/O等待所消耗,也就是存储系统的性能不足导致了应用的性能比较差。

    该实例表明了以下事实:数据库中只有少部分数据需要高存储性能(IOPS),大部分数据对存储性能(IOPS)的要求较低。在OLTP、数据库应用环境下,通过增加存储系统中磁盘数量来提升存储性能(IOPS),以满足少部分数据对高性能(IOPS)的需求,这种方式是否经济合理,用户应该算一算账,并重新审视一下。

    相关链接:Curtis公司的IT系统能力评估分析和优化服务

    虽然分层存储解决方案能在满足用户对存储容量和性能需求的同时,降低用户存储的TCO,但实施分层存储需要用户了解其应用对存储性能(IOPS)的需求,以及数据对IOPS的需求分布(即哪些、多少数据需要什么水平的IOPS),而这并不是每一个用户都能做到的。

    Curtis公司免费提供的IT系统能力评估分析和优化服务,其目标是帮助用户更好地理解其现有IT系统的能力、性能和局限性,向用户提供现有以及未来所需计算资源(包括存储资源)的报告,并向用户提供IT系统规划和优化建议。借助Curtis 公司免费提供的IT系统能力评估分析和优化服务,用户可方便地实施分层存储解决方案。

    Curtis公司免费提供的IT系统能力评估分析和优化服务的具体流程如下。

    客户环境下相关系统和应用的研究 了解需要进行规划和优化的系统和应用的功能及现有能力。

    确定重要的性能参数和度量标准 按照IT系统能力评估分析和优化服务及客户的需求,确定应用的从属或者系统相关性;影响应用性能的度量标准的采样等;系统相关性能度量标准的采样等。

    基准脚本的客户定制 脚本定制以客户需求为基础;脚本样本包括存储(STKIO和IOGEN)、网络(NETPERF和NETTEST)以及处理器(SPEC and Byte);所采用的脚本以过去的客户经验为基础。

    适当时间段内数据样本的采集在客户系统上执行定制脚本就可以得到分析所需的性能数据;对客户网络工作负载的影响最小化;收集的样本用来描述现有特征;以这些数据为基准与未来数据进行比较。

    数据分析 获得性能参数以后,就可以进行趋势分析;矩阵结构能对性能指标进行相关性和对照性分析;进行可扩展性和设定分析;优化方案的结论和建议。

    IT系统能力评估分析和优化服务结果的档案记录和提交 对结论及其含义的解释;对下一步系统解决方案结构的建立,或优化系统配置的建议规划。

    表2 Fujitsu ETERNUS系列盘阵SPC-1基准测试比对

    表3 IBM DS系列盘阵SPC-1基准测试比对

    表4 Fujitsu ETERNUS系列盘阵SPC-1基准测试比对

    表5 IBM DS系列盘阵SPC-1基准测试比对

  • 相关阅读:
    一波骚操作,我把 SQL 执行效率提高了 10,000,000 倍!
    如何优雅地根治null值引起的Bug!
    解锁新姿势:探讨复杂的 if-else 语句“优雅处理”的思路
    39 个奇葩代码注释,看完笑哭了。。。
    只要学会它,再多 Bug 也不怕
    SpringBoot 快速整合Mybatis(去XML化+注解进阶)
    Java 并发异步编程,原来十个接口的活现在只需要一个接口就搞定!
    微服务 2.0 技术栈选型手册
    如何设计 API 接口,实现统一格式返回?
    别在 Java 代码里乱打日志了,这才是打印日志的正确姿势!
  • 原文地址:https://www.cnblogs.com/jjkv3/p/2444346.html
Copyright © 2011-2022 走看看