随机环境下系统性能调优指南

港控/mmm° 2022-08-24 04:28 172阅读 0赞

嘿嘿，前不久听EMC的一个讲座，其中有一个讲座是讲磁盘阵列性能调优的一些原则的。感觉非常实战，很多原则性的东西非常有用。回来整理了一下，发给大家共享。虽然不是100%原创，但确实感觉内容不错才给整理出来的哦  
  
应该是分成两部分，一部分讲随机IO，一部分讲顺序IO环境。现在只整理出了随机IO，先给大家看看，欢迎大家拍砖讨论：  
  
EMC创新日：随机环境系统性能调优指南  
  
**理解随机IO和顺序IO的特点**  
  
　　对于随机应用来说，大部分是一些数据库的应用，此外，Oracle ASM也是属于随机应用，但每个IO段都比较大，所以导入起来时间比较长。除了随机应用，系统中通常还会有顺序读写的IO应用，一般来说在归档、视频等等的应用比较常见。它们对性能的要求是不太一样的，规模也是不一样的。针对这两种IO特点，我们通常由一些配置的原则，但不见得哪一种是贯穿的。  
  
　　随机应用要求是响应时间，我们每一个IO都希望在几毫秒内完成，然后才可以进行下一个IO操作。顺序读写要求带宽比较高，这种情况下，一个IO过来，很可能一读就占了几M或者十几M，这时候一个IO的操作就占用了整个阵列。其他IO就会被迫排在它的后面，顺序IO就占用了太多的资源，并占用了其他IO的资源。例如本来在1秒钟可以处理1000个IO，现在只能处理700个IO。所以我们就建议不要把顺序读写放在同一个磁盘上面，但是我们可以把它放在一排阵列上面没有问题，最好用不同的磁盘来分散IO压力。  
  
**性能调优的通用原则**  
  
详细分析随机环境下的IO特点之前，我们会先给出一些存储系统调优最基本的原则。这些原则基本适用于大多数应用环境，无论是随机IO的环境还是顺序IO的环境。  
  
　　 **读Cache设置：**一般会认为读cache在阵列中是提高性能的非常有用的措施，对于一些应用来说，大部分时候读cache的确非常有效。但是一个原则是不要分配太多的读Cache给系统，一般日常的工作状态中，分配20%左右的读Cache就已经足够了。原因有两点，首先，在随机IO的应用状态下，我们不能保证所需要读取的IO能在缓存中命中。其次，在顺序IO的读取过程中，从磁盘中读取IO的速度并不慢，先读到缓存中对整体读取速度的提高没有太明显的影响。因此，通常的一个标准就是，读缓存设置20%左右就足够了。  
  
　　 **选型配制时不仅需要考虑容量，还需要考虑性能：**其次，当我们在进行存储选型或者配置的时候，我们不仅仅需要考虑存储系统的容量，我们还需要考虑性能的因素。举个例子来说，从容量的角度，我们可能4块磁盘就足够满足应用，另外一个方面四块磁盘不一定能够满足我们对IO性能的要求。举例来说，一块15K转硬盘在非常随机的IO状态下能提供180个IOPS，如果是4块盘，大概就只有720个IOPS，究竟是否能满足性能的需要？  
  
　　 **系统盘中是否能够存放应用数据？**此外，CLARiiON中有5块盘作为系统盘使用。应该说，系统盘中其实有一定的空间给我们使用，我们同样可以应用系统盘中间的空间进行编组，划分LUN。但这是在IO的压力并不是十分大的情况下，应用系统盘的空间对阵个系统的影响不大。当IO压力很大的时候，我们不建议把应用的LUN放到系统盘上面，会导致整体系统的响应速度变慢。  
  
　　而且有一种情况，在阵列中有一个HA VAULT选项，这个选项的作用就是当系统盘一旦出现故障以后，这个选项能够自动将cache里面的数据文本下载到系统盘上面去，如果这时候系统盘还有其他的应用在访问，这时候系统要同时把数据从cache里面DOWN到磁盘里面，两个应用都在系统磁盘上操作，这样速度也会变慢。当然这个选项可以取消它，但带来的负面因素就是，当系统出现故障的时候，无法自动的把数据从cache下载到磁盘里面，可靠性会降低。  
  
　　 **选择合适的磁盘类型：**当进行存储选型的时候，我们通常会有FC、SAS和SATA几种磁盘类型。FC盘和SAS盘等适用于关键实时应用， SATA盘性能比较低，我们通常用在归档的环境。但是如果你的访问是顺序的，基本上一个访问，你这时候你可以用SATA盘。

把不同的随机应用混在一起  
  
　　下面我们重点讨论一下随机IO的应用。对于一些用户来说，往往很疑惑，我有几个不同的随机IO的应用，对于这些不同的随机IO的应用，我们要不要分在不同的RAID组，或者不同的LUN中。其实对于存储系统来说，我们会发现，不同的随机IO即使混合在一起，也同样是随机的IO，对于这些不同的应用，我们即使划分在一个RAID组或者LUN里面，对单个应用的性能都不会有太多的影响。  
  
　　此外，随机IO应用的高峰期通常不会完全重合，当随机IO处于高峰期的时候相互之间的确会产生影响，因此对于用户来说，我们需要注意的就是，如果同时有两个随机IO的应用高峰期大致相同，且其中一个的应用对性能的要求很高，需要有一定的资源保证，在这种情况下，我们需要把这个应用独立出来划分LUN。如果这些随机IO的高峰期并不是非常一致，且没有需要保证高性能的应用的情况下，我们可以大胆的把这些应用混在一起，这样我们能够用更多的磁盘来担负多个应用的IO需求，不仅不会对性能造成影响，还能有效的消除热点。  
  
![attachment.php_checkimg_ok_aid_304945_noupdate_yes][] ![attachimg.gif][]  
不同的随机应用混合在一起还是随机应用  
  
　　我们关注一下数据库的应用，对于关系型数据库来说往往LOG是比较重要的，我们通常会单独划分空间来保存LOG，在需要很高性能的时候这样做的确是必须的而且是有效的。但是如果系统对性能要求并不十分苛刻的话，我们其实可以大胆的把LOG和数据放到一起，因为它占用性能的影响其实没有我们想象那么大。很多时候，LOG都是顺序的少量的写IO，通常IO写到Cache里面，读的话不会占用所有的cache。当我们把LOG和数据放到一起，我们能用更多的磁盘来完成LOG读写IO的操作，此外，LOG本身对性能的影响本身也并不十分明显。因此我们建议，在对性能没有苛刻要求的情况下，完全可以把非关系型数据库的LOG和数据放到一起。  
  
![attachment.php_checkimg_ok_aid_304946_noupdate_yes][] ![attachimg.gif][]  
两个不同数据库的LOG和数据交叉存放  
  
　　一个实用的技巧，是把两个不同的数据库的LOG和数据交叉存放，来保护数据或者错峰使用。

**选择什么样的RAID级别？**  
  
　　对于随机IO的分布来说我们还需要考虑我们到底选择什么样的RAID级别，不同的RAID级别对磁盘的要求是不同的，对于综合性能来说，RAID是最值得期待的。  
  
　　通常RAID5是一个综合成本和性能的很好的选择，但是我们什么情况下需要采用RAID0+1呢？实际上一般的应用来说，占绝大多数的都是读IO，其中写IO通常占到10%左右。但是，当我们分析写IO超过20%的时候，我们就应该考虑采用RAID0+1，这种情况下，如果不要求太高的性能，RAID5也是可以接受的。但是当写IO超过了40%左右，那么我们就必须考虑采用RAID0+1了。  
  
　　因为不同的RAID方式对磁盘产生的IO（Disk IO）是不同的。举例来说，一个四块磁盘的RAID5要做一个写操作时，所产生的磁盘IO实际上是4个，包括2个读IO和2个写IO。而同样一个写IO，在一个四块磁盘的RAID 0+1组中，所产生的磁盘IO实际上只有2个，实际上只需要同时写到两个磁盘中就可以了。因此，当一个应用中的写IO越高，那么对于RAID5和RAID0+1的性能影响就会体现的越明显。  
  
　　那什么时候使用RAID6呢，首先要求写操作的比率比较低，低于15%的时候可以考虑使用RAID6。读操作的时候RAID5和RAID6相差不多，但是它比RAID5对系统的影响更大，因为一个post IO通常会在后端产生6个磁盘IO。所以，首先RAID 6在写IO操作并不十分多的情况下应用会比较好，另外就是应用在数据完整性方面的要求的确非常高。  
  
![attachment.php_checkimg_ok_aid_304947_noupdate_yes][] ![attachimg.gif][]  
  
相同应用下不同的RAID级别的性能差别  
  
　　如图的这个案例，2100个IOPS，其中30%的写IO，在RAID0+1的情况下，磁盘利用率达到70%，响应时间13ms，而换到RAID5的情况下，磁盘利用率就达到了92%，响应时间变成了62ms，很多应用都不能接受62ms的响应时间。而对于RAID6来说，写操作完全没办法满足应用要求。  
  
　　RAID条带宽度对性能会带来什么影响呢？RAID条带宽度主要与RAID组的磁盘数据是有关系的。一般来说，一个磁盘片的宽度是64K，如果是3+1的RAID组就是64K\*3，7+1的RAID组就是64K\*7。在随机应用的环境中，带宽对整体性能并没有明显的影响。但是当一个RAID组中的磁盘数量过多的时候，在磁盘出现故障需要重建的时候，磁盘会当机。

**矫正偏移量**  
  
　　另外有一个很关键的问题就是偏移量（Alignment），偏移量基本上产生在WINDOWS平台，或者Wintel架构中。因为在WINDOWS平台里面，每个磁盘都留有一部分空间用来存放分区表，系统在启动的时候会有很多的信息在里面，一般为32K。由于我们知道一个盘片的基本容量在64K，那么这个盘片还有32K的可用空间。当一个大于32K的写IO过来的时候，这时候就需要2个磁盘或者更多的磁盘来完成这个IO操作，这就是偏移量。  
  
　　偏移量对系统的整体性能有非常大的影响，那么我们通过什么方式能够调整呢？对于wintel的架构，我们可以通过diskpar工具来设定偏移量，例如将数据块大小设为64K，这样写操作的时候，数据将自动从第二块磁盘去写入。在虚拟机的环境下，如果是RDM的LUN环境，我们可以在虚拟机层面使用diskpar工具工具设定偏移量，如果是VMFS的LUN环境，我们需要先在ESX上使用FDISK，然后在虚拟机层面使用diskpar工具工具设定偏移量。  
  
　　偏移量是个很重要的问题，但很多用户会很容易忽视它。我们举个例子来说明，在没有矫正偏移量的情况下，系统性能会损失多少。一般来说，最常用的数据块大小除以64，就是我们损失的性能比。如果常用数据块为8K，那么损失的性能为8/64=12.5%。  
  
**Oracle ASM环境下性能调优**  
  
　　对于Oracle ASM的环境，一般来说是大数据块的随机写入。如果我们对系统进行优化，通常会自动的把数据拆分成小数据块，例如8K、16K，对于这些小数据块来说主要是顺序读写，尽管整个大的数据块保持了随机读写的特性。在这种环境下，我们需要注意：  
  
　　无论对于R26以前或者以后的版本，首先每一个RAID组设置1 或2 LUNs。  
　　对于R26以前版本  
– RAID 1/0 条带化成256 blocks时性能最好(需要在命令行或工程模式下进行)  
– 2+2, 4+4 的条带吻合I/O 块大小  
– 对齐偏移量! 比小数据块的随机访问环境更关键  
– 把数据LUN的读高速缓存关掉-- 基本用不上  
  
　　在Release 26及更高版本, CLARiiON支持‘multi-stripe read’  
– RAID 1/0 2+2 的配置比较合适，可以让磁盘支持大的数据块读操作(高达512 KB).  
– 使用条带化的MetaLUN, 8的倍数来获得更大的分区和分散热点数据  
– 支持发送1MB的I/O到成员LUN上, 每个磁盘的处理I/O高达512 KB。

**随机访问性能调优规则总结**  
  
　　最后我们总结一下在随机访问的时候获得最高性能的一些规则。  
  
　　首先是缓存：  
  
　　把缓存页面设置成主导I/O的大小，在混合环境中建议使用8KB大小。但需要注意的是，改变缓存页面大小必须关闭高速缓存，须预先计划影响  
  
　　如果系统的写操作响应时间较长，把缓存水平线的阀值降低。这样做的好处包括：简单，无需中断；在高速缓存中预留更大的空间，以应付写操作的高峰。但需要注意的是，水平线的高值应该比低值高20%。  
  
　　此外我们可以关闭随机访问的LUN上的预读功能，因为一些文件系统对数据的存取导致大量的预读操作，但是并没有帮助，而且这样做简单，无需中断。  
  
　　对一些有随机特征的顺序操作(常见于媒体应用)，应该增加预读的功能。中央视频监控是一种典型的例子，而且这样做同样简单并无需中断。  
  
　　此外，对磁盘数量大小的设定也对性能有明显的影响，一般来说，单个磁盘臂提供的IOPS决定随机存取的性能。在进行选型之前，我们需要计算计算所需IOPS的性能需求，包括主机产生的压力及RAID算法额外产生的I/O负荷。  
  
　　下面提供一些经验数据值，在70%使用率，非常随机的读取目标情况下：  
　　15K rpm FC/SAS能够提供180 IOPS，10K rpm FC/SAS能够提供140 IOPS，7.2K rpm SATA能够提供80 IOPS。因此用户需要根据根据IOPS的需求决定支持的磁盘数，然后选择相应的阵列，很多用户会用到阵列所支持的最大磁盘数。

[attachment.php_checkimg_ok_aid_304945_noupdate_yes]: http://bbs.chinaunix.net/attachment.php?checkimg=ok&aid=304945&noupdate=yes
[attachimg.gif]: http://bbs.chinaunix.net/images/default/attachimg.gif
[attachment.php_checkimg_ok_aid_304946_noupdate_yes]: http://bbs.chinaunix.net/attachment.php?checkimg=ok&aid=304946&noupdate=yes
[attachment.php_checkimg_ok_aid_304947_noupdate_yes]: http://bbs.chinaunix.net/attachment.php?checkimg=ok&aid=304947&noupdate=yes