http://dnbcw.com/biancheng/html/sql/duto46294.html
对磁盘IO的性能考虑：
1) 将频繁访问的文件系统和裸设备应尽可能放置在不同的磁盘上。
2) 在建立逻辑卷时尽可能使用mklv的命令开关给不同的文件系统和裸设备赋予不同的内策略。
3) 使用磁盘设备驱动适配器的功能属性构建合适的RAID方式,以获得更高的数据安全性和存取性能。一般考虑采用RAID5或者RAID10方式，对于写要求比较高的系统，一般建议采用RAID10方式;关于RAID10 与RAID 5的比较，可以见piner的文章，作为补充我会在后面贴出。
4) 尽可能利用内存读写带宽远比直接磁盘I/O操作性能优越的特点,使频繁访问的文件或数据置于内存中进行操作处理;
在这里，顺带提一下裸设备以及文件系统的对比。
裸设备的优点：
1) 由于旁路了文件系统缓冲器而进行直接读写，从而具有更好的性能。对硬盘的直接读写就意味着取消了硬盘与文件系统的同步需求。这一点对于纯OLTP系统非常有用，因为在这种系统中，读写的随机性非常大以至于一旦数据被读写之后，它们在今后较长的一段时间内不会得到再次使用。除了OLTP，raw设备还能够从以下几个方面改善DSS应用程序的性能：
排序：对于DSS环境中大量存在的排序需求，raw设备所提供的直接写功能也非常有用，因为对临时表空间的写动作速度更快。
序列化访问：raw设备非常适合于序列化I/O动作。同样地，DSS中常见的序列化I/O(表/索引的完全扫描)使得raw设备更加适用于这种应用程序。
2) 直接读写，不需要经过OS级的缓存。节约了内存资源，在一定程度上避免了内存的争用。
3) 避免了操作系统的cache预读功能，减少了I/O。
4) 采用裸设备避免了文件系统的开销。比如维护I-node，空闲块等。
裸设备的缺点：
1、裸设备的空间大小管理不灵活。在放置裸设备的时候，需要预先规划好裸设备上的空间使用。还应当保留一部分裸设备以应付突发情况。这也是对空间的浪费。
2、很多备份工具软件对裸设备的支持不足，导致备份等的操作和方法比较原始、麻烦。
接下来，对于磁盘I/O的性能性能评估的方法。
AIX系统磁盘I/O性能评估第2部分：(电脑编程网整理，请尊重作者权益，转载注明出处;)
1、iostat查看
| #iostat 1 3 System configuration: lcpu=16 drives=11 paths=4 vdisks=0 tty: tin tout avg-cpu: % user % sys % idle % iowait Disks: % tm_act Kbps tps Kb_read Kb_wrtn tty: tin tout avg-cpu: % user % sys % idle % iowait Disks: % tm_act Kbps tps Kb_read Kb_wrtn tty: tin tout avg-cpu: % user % sys % idle % iowait Disks: % tm_act Kbps tps Kb_read Kb_wrtn |
注意：第一个报告代表自系统启动以来所有的活动。
下面对输出的结果说明如下：
¨ tty TTY 的两列信息(tin 和 tou)显示了由所有 TTY 设备读写的字符数。
¨ avg-cpu CPU 统计信息列(% user、% sys、% idle 和 % iowait)提供了 CPU 的使用故障。如果 iostat 命令表明 CPU 受限的情况不存在，并且 % iowait 时间大于 20%，则可能出现 I/O 或磁盘受限情况。这一情况可能在缺少实内存的情况下由过多调页产生。也有可能是由于不平衡的磁盘负载、碎片数据或应用模式而产生。
¨ % tm_act 指示物理磁盘活动所占总时间的百分比(磁盘的带宽利用率)，或者换句话说，磁盘请求的总时间未达到。驱动器在数据传送和处理命令时是活动的，例如寻道至新的位置。“磁盘活动时间”百分比正比于资源争用，反比于性能。当磁盘使用率增加时，性能就下降并且响应时间就增加。一般来说，当利用率超过 70% 时，进程将等待的时间会比完成 I/O 所必需的时间更长，因为大多数 UNIX 进程在等待它们的 I/O 请求完成时会阻塞(或休眠)。查找相对空闲驱动器来说繁忙的驱动器。把数据从繁忙的驱动器中移到空闲驱动器里可以帮助减轻磁盘的瓶颈。在磁盘中调入调出页面会使 I/O 负载增加。
¨ Kbps指示了每秒钟多少 KB 的数据被传送(读或写)。这是在系统报告时间间隔内 Kb_read 加上 Kb_wrtn 的总和并除以的这段时间间隔的总数的结果。
¨ tps 指示了每秒钟物理磁盘传送的次数。一次传送是设备驱动程序级别到物理磁盘的一次 I/O 处理请求。多重逻辑请求可以组合成单一的磁盘 I/O 请求。传送的大小是不确定的。
¨ Kb_read报告了在测量间隔中总的从物理卷中读取的数据量(以 KB 为单位)。
¨ Kb_wrtn显示了在测量间隔中总的写入物理卷中的数据量(以 KB 为单位)。
我们也可以针对适配器作性能评估。想知道某个适配器是否饱和，使用 iostat 命令并且把所有连接到这个适配器上的磁盘的 Kbps 数量加起来。为了获得最大的聚集性能，总的传送率(Kbps)必须在磁盘适配器的吞吐量之下。在大多数情况下，使用 70% 的吞吐量，-a 或 -A 选项会显示这些信息。
| #iostat -a 1 1 System configuration: lcpu=16 drives=11 paths=4 vdisks=0 tty: tin tout avg-cpu: % user % sys % idle % iowait Adapter: Kbps tps Kb_read Kb_wrtn Disks: % tm_act Kbps tps Kb_read Kb_wrtn Adapter: Kbps tps Kb_read Kb_wrtn Disks: % tm_act Kbps tps Kb_read Kb_wrtn Adapter: Kbps tps Kb_read Kb_wrtn Disks: % tm_act Kbps tps Kb_read Kb_wrtn Adapter: Kbps tps Kb_read Kb_wrtn Disks: % tm_act Kbps tps Kb_read Kb_wrtn Adapter: Kbps tps Kb_read Kb_wrtn Disks: % tm_act Kbps tps Kb_read Kb_wrtn Adapter: Kbps tps Kb_read Kb_wrtn Disks: % tm_act Kbps tps Kb_read Kb_wrtn |
AIX系统磁盘I/O性能评估第3部分：(电脑编程网整理，请尊重作者权益，转载注明出处;)
2、sar –d查看
| #sar -d 1 2 AIX jsdxh_db01 3 5 00C2C1BB4C00 10/24/07 System configuration: lcpu=16 drives=11 21:05:38 device %busy avque r+w/s Kbs/s avwait avserv 21:05:39 hdisk1 0 0.0 0 0 0.0 0.0
|
输出结果说明：
¨ device 设备的类型
¨ %busy 报告设备忙于执行传输请求所用的时间
¨ avque 该段时间内未完成的请求的平均值。
¨ r+w/s 进车设备的读/写传送次数。
¨ blks/s 以512字节为单元的传送数
¨ avwait 不执行，总是设置为 0.0
¨ avserv 不执行，总是设置为 0.0
AIX系统磁盘I/O性能评估第4部分：(电脑编程网整理，请尊重作者权益，转载注明出处;)
3、使用lslv –l lvname来评估逻辑卷的碎片情况
| # lslv -l hd2 hd2:/usr PV COPIES IN BAND DISTRIBUTION hdisk0 114:000:000 22% 000:042:026:000:046 |
输出字段说明：
¨ PV 物理卷名称
¨ Copies三个字段分别代表
在物理卷上至少包含一个物理分区(没有副本)的逻辑分区的数量
在物理卷上至少包含两个物理分区(一个副本)的逻辑分区的数量
在物理卷上至少包含三个物理分区(两个副本)的逻辑分区的数量
¨ In band center分配策略占用的百分比。
¨ Distribution 分配在物理卷每个区域内：物理卷的外部边缘、外部中间、中间、中心和内部边缘的物理分区的数目
对于该例中的结果说明如下：
copies显示逻辑卷hd2只复制了一份。IN BAND显示了内策略是如何遵循的。这个百分比越高，分配效率就越好。在这个示例中，有总共114个逻辑分区(LP)，42个位于中部，26个位于中心，还有46个位于内边缘。in band占用22%(26/(42+26+46))。DISTRIBUTION显示物理分区的具体的内策略部署，格式如下：
outer-edge : outer-middle : center : inner-middle : inner-edge
关于物理卷内分配策略说明：
指定物理卷上选择物理分区时使用何种策略。五种常用的策略时边缘、内层边缘、中部、内层中部和中心。鉴于磁盘的读取方式，数据写入磁盘中心部分的寻道时间比写入外部边缘的寻道时间短。
AIX系统磁盘I/O性能评估第5部分：(电脑编程网整理，请尊重作者权益，转载注明出处;)
4、lslv –p 评估物理布局
可以使用lslv –p hdiskN来查看在物理磁盘上的数据存储分布情况，同时也可以看到使用该内策略的逻辑卷以及挂载的文件系统。
| #lspv -p hdisk3 hdisk3: PP RANGE STATE REGION LV NAME TYPE MOUNT POINT 1-30 free outer edge 31-110 used outer edge ocsapplv jfs /ocsapp 111-206 used outer middle paging00 paging N/A 207-219 free outer middle 220-328 free center 329-437 free inner middle 438-546 free inner edge |
AIX系统磁盘I/O性能评估第2部分：(电脑编程网整理，请尊重作者权益，转载注明出处;)
9、RAID10和RAID5的比较
这篇是piner写的，我稍微增加了点点内容。
为了方便对比，这里拿同样多驱动器的磁盘来做对比，RAID5选择3D+1P的RAID方案，RAID10选择2D+2D的RAID方案，如图：
1、安全性方面的比较
其实在安全性方面，勿须质疑，肯定是RAID10的安全性高于RAID5。我们也可以从简单的分析来得出。当盘1损坏时，对于RAID10，只有当盘1对应的镜象盘损坏，才导致RAID失效。但是对于RAID5，剩下的3块盘中，任何一块盘故障，都将导致RAID失效。
在恢复的时候，RAID10恢复的速度也快于RAID5。
2、空间利用率的比较
RAID10的利用率是50%，RAID5的利用率是75%。硬盘数量越多，RAID5的空间利用率越高。
3、读写性能方面的比较
主要分析分析如下三个过程：读，连续写，离散写。
在介绍这三个过程之前，先介绍一个特别重要的概念：cache。
cache已经是整个存储的核心所在，就是中低端存储，也有很大的cache存在，包括最简单的raid卡，一般都包含有几十，甚至几百兆的raid cache。
cache的主要作用是什么呢?体现在读与写两个不同的方面，如果作为写，一般存储阵列只要求写到cache就算完成了写操作，所以，阵列的写是非常快速的，在写cache的数据积累到一定程度，阵列才把数据刷到磁盘，可以实现批量的写入，至于cache数据的保护，一般都依赖于镜相与电池(或者是UPS)。
cache的读一样不可忽视，因为如果读能在cache中命中的话，将减少磁盘的寻道，因为磁盘从寻道开始到找到数据，一般都在6ms以上，而这个时间，对于那些密集型io的应用可能不是太理想。但是，如果cache能命中，一般响应时间则可以在1ms以内。两者应该相差3个数量级(1000倍)。
1)读操作方面的性能差异
RAID10可供读取有效数据的磁盘个数为4，RAID5可供读取有效数据的磁盘个数也为4个(校验信息分布在所有的盘上)，所以两者的读的性能应该是基本一致的。
2)连续写方面的性能差异
在连续写操作过程，如果有写cache存在，并且算法没有问题的话，RAID5比RAID10甚至会更好一些，虽然也许并没有太大的差别。(这里要假定存储有一定大小足够的写cache，而且计算校验的cpu不会出现瓶颈)。
因为这个时候的RAID校验是在cache中完成，如4块盘的RAID5，可以先在内存中计算好校验，同时写入3个数据+1个校验。而RAID10只能同时写入2个数据+2个镜相。
如上图所示，4块盘的RAID5可以在同时间写入1、2、3到cache，并且在cache计算好校验之后，这里假定是6，同时把三个数据写到磁盘。而4块盘的RAID10不管cache是否存在，写的时候，都是同时写2个数据与2个镜相。
根据前面对缓存原理的介绍，写cache是可以缓存写操作的，等到缓存写数据积累到一定时期再写到磁盘。但是，写到磁盘阵列的过程是迟早也要发生的，所以RAID5与RAID10在连续写的情况下，从缓存到磁盘的写操作速度会有较小的区别。不过，如果不是连续性的强连续写，只要不达到磁盘的写极限，差别并不是太大。
3)离散写方面的性能差异
例如oracle 数据库每次写一个数据块的数据，如8K;由于每次写入的量不是很大，而且写入的次数非常频繁，因此联机日志看起来会像是连续写。但是因为不保证能够添满RAID5的一个条带，比如32K(保证每张盘都能写入)，所以很多时候更加偏向于离散写入(写入到已存在数据的条带中)。
我们从上图看一下离散写的时候，RAID5与RAID10工作方式有什么不同。如上图：我们假定要把一个数字2变成数字4，那么对于RAID5，实际发生了4次io：先读出2与校验6，可能发生读命中然后在cache中计算新的校验写入新的数字4与新的校验8。
如上图我们可以看到：对于RAID10，同样的单个操作，最终RAID10只需要2个io，而RAID5需要4个io.
这里我忽略了RAID5在那两个读操作的时候，可能会发生读命中操作的情况。也就是说，如果需要读取的数据已经在cache中，可能是不需要4个io的。这也证明了cache对RAID5 的重要性，不仅仅是计算校验需要，而且对性能的提升尤为重要。
当然，并不是说cache对RAID10就不重要了，因为写缓冲，读命中等，都是提高速度的关键所在，只不过RAID10对cache的依赖性没有RAID5那么明显而已。
4)磁盘的IOPS对比
假定一个case，业务的iops是10000，读cache命中率是30%，读iops为60%，写iops为40%，磁盘个数为120，那么分别计算在raid5与raid10的情况下，每个磁盘的iops为多少。
raid5:
单块盘的iops = (10000*(1-0.3)*0.6 + 4 * (10000*0.4))/120
= (4200 + 16000)/120
= 168
这里的10000*(1-0.3)*0.6表示是读的iops，比例是0.6，除掉cache命中，实际只有4200个iops。
4 * (10000*0.4) 表示写的iops，因为每一个写，在raid5中，实际发生了4个io，所以写的iops为16000个
为了考虑raid5在写操作的时候，那2个读操作也可能发生命中，所以更精确的计算为：
单块盘的iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4)*(1-0.3) + 2 * (10000*0.4))/120
= (4200 + 5600 + 8000)/120
= 148
计算出来单个盘的iops为148个，基本达到磁盘极限
raid10
单块盘的iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4))/120
= (4200 + 8000)/120
= 102
可以看到，因为raid10对于一个写操作，只发生2次io，所以，同样的压力，同样的磁盘，每个盘的iops只有102个，还远远低于磁盘的极限iops。
4、小结
所以要求较高的空间利用率，对安全性要求不是特别高、大文件存储的系统采用RAID5比较好。
相反，安全性要求很高，不计成本，小数据量频繁写入的系统采用RAID10的方式比较好。
AIX系统磁盘I/O性能评估第8部分：(电脑编程网整理，请尊重作者权益，转载注明出处;)
7、监视磁盘 I/O 的小结
一般来说，高的 % iowait 表明系统存在一个应用程序问题、缺少内存问题或低效的 I/O 子系统配置。例如，应用程序的问题可能是由于许多 I/O 请求，而不是处理许多数据。理解 I/O 瓶颈并且要清楚解决瓶颈问题的关键在于提高 I/O 子系统的效率。磁盘的灵敏度可以以几种方式出现，并具有不同的解决方法。一些典型的解决方案可能包括：
¨ 限制在特定的物理磁盘上活动逻辑卷和文件系统的数目。该方法是为了在所有的物理磁盘驱动器中平衡文件 I/O。
¨ 在多个物理磁盘间展开逻辑卷。该方法在当有一些不同的文件被存取时特别有用。
¨ 为一个卷组创建多个 Journaled 文件系统(JFS)日志并且把它们分配到特定的文件系统中(最好在快速写高速缓存驱动器中)。这对应用程序创建、删除或者修改大量文件特别是临时文件来说十分有益。
¨ 如果 iostat 命令的输出结果表明您的负载的 I/O 活动没有被均衡地分配到系统磁盘驱动器中，并且一个或多个磁盘驱动器的使用率经常在 70-80 之间或更高，您就得考虑重组文件系统，例如备份和恢复文件系统以便减少碎片。碎片将引起驱动器过多地搜索并且可能产生大部分响应时间过长。
¨ 如果很大，I/O 增强的后台作业将涉及和相应时间交互，您可能希望激活I/O 调步。
¨ 如果有迹象表明一小部分文件被一次又一次地读取，您可以考虑附加的实存是否允许那些文件更加有效地缓存。
¨ 如果负载的存取模式是随机占主导地位，您可能要考虑增加磁盘并把按那些随机存取的文件分布到更多的磁盘中。
¨ 如果负载的存取模式是顺序占主导地位并且涉及多个磁盘驱动器，您可能要考虑增加一个或多个磁盘适配器。您也可以适当地考虑构建一个条带状逻辑卷来适应大型并且性能关键的顺序文件。
¨ 使用快速写高速缓存设备。
¨ 使用异步 I/O。
AIX系统磁盘I/O性能评估第9部分：(电脑编程网整理，请尊重作者权益，转载注明出处;)
8、案例
说明：这个案例不是我的，不记得在哪里找的：
| # sar 1 5 01:24:21 %usr %sys %wio %idle 01:24:51 46 5 28 21 01:25:21 46 5 29 20 01:25:51 47 5 30 20 01:26:21 44 5 29 22 01:26:51 45 5 28 22 Average 46 5 29 21 |
在CPU资源尚未耗尽的情况下,有近1/3的CPU时间在等待磁盘I/O,可以肯定系统资源调度中I/O存在瓶颈;进而监控I/O使用情况:
| # iostat –d hdisk3 1 10 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk3 52.1 1086.9 262.6 1025224 1967060 hdisk3 93.0 4704.0 1121.0 636 4068 hdisk3 98.0 1236.0 294.0 400 836 hdisk3 92.0 1556.0 386.0 780 776 hdisk3 81.0 760.0 178.0 696 64 hdisk3 89.0 1032.0 252.0 824 208 hdisk3 92.0 1376.0 329.0 708 668 hdisk3 99.0 1888.0 457.0 292 1596 hdisk3 98.0 1436.0 356.0 660 776 hdisk3 94.0 1624.0 403.0 852 772 hdisk3 99.0 2412.0 589.0 724 1688 |
可以发现hdisk3平均访问率非常高,几乎在90%以上,但从数据传输量来看其真正的数据量并不大,约为1500Kbps,而且读写均衡,说明运行的应用程序的对磁盘访问有小数据量频繁存取的特点(其实即为电信应用中话务呼叫的应用特点);这里可以肯定的是系统整体性能的瓶颈在于hdisk3的过度访问. 更进一步分析,使用系统监控命令filemon 或 lvmstat可以获得以下信息:
| #filemon –o filemon.out; sleep 30; trcstop #vi filemon.out(部分截取) util #rblk #wblk KB/s volume description ------------------------------------------------------------------------ 1.00 91080 108112 1561.1 /dev/workdbslv1 raw 0.00 0 4072 31.9 /dev/logiclogdbslv raw 0.00 8 4384 34.4 /dev/tcom_filelv /tcom_file 0.00 0 120 0.9 /dev/hd4 / 0.00 0 144 1.1 /dev/hd2 /usr 0.00 0 88 0.7 /dev/loglv01 jfslog 0.00 0 272 2.1 /dev/tcomlv /tcom 0.00 0 32 0.3 /dev/hd8 jfslog 0.00 0 104 0.8 /dev/loglv00 jfslog 0.00 0 8 0.1 /dev/hd3 /tmp Most Active Physical Volumes |
hdisk3的过分繁忙是由于其中的用于放置数据库表的/dev/workdbslv1裸设备过度繁忙造成的,至此我们可以通过调整裸设备的放置策略和数据库配置参数获得更好的I/O性能:
1.建立workdbslv1时裸设备时使用如下命令调整:
# mklv -y workdbslv1 -t raw –a’c’ datavg 128 hdisk3 hdisk4
hdisk3和hdisk4为属于同一个卷组的两个7133RAID逻辑盘。指定内分配策略。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-605118/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/35489/viewspace-605118/
293
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
