从系统层面介绍几个诊断性能问题的方法和路径：
1.某个操作响应慢

2.系统整体慢
1）vmstat
$vmstat 1 2
System configuration: lcpu=16 mem=23552MB
kthr memory page faults cpu
----- ----------- -------------- ----------------- -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
0 0 3091988 2741152 0 0 0 0 0 0 1849 26129 4907 8 1 88 3
0 0 3091989 2741151 0 0 0 0 0 0 2527 32013 6561 15 2 77 6

Kthr段显示内容
r列：表示可运行的内核线程平均数目，包括正在运行的线程和等待 CPU 的线程。如果这个数字大于 CPU 的数目，则表明有线程需要等待CPU。
b列：表示处在非中断睡眠状态的进程数。包括正在等待文件系统 I/O 的线程，或由于内存装入控制而被挂起的线程。如果 r 不大于 b，通常是 CPU 问题的症状，这可能是由于 I/O 或者内存瓶颈造成的。

Memory段显示内容
avm列：表示活动虚拟内存的页面数，每页一般4KB，不包括文件页面。
fre列：内存空闲列表的大小。在大多数情况下，我并不担心这个值什么时候变得很小，因为 AIX 总是会充分地使用内存，并且不会像您希望的那样尽早地释放内存。这个设置由 vmo 命令的 minfree 参数来确定。归根结底，分页的信息更加重要。

Page段显示内容
re列：该列无效
pi列：从磁盘交换到内存的交换页（调页空间）数量，4KB/页。调页空间是驻留在硬盘上的虚拟内存的一部分。当内存使用过量时，会将溢出的工作组页面存储到调页空间中（窃取页）。当进程访问一个窃取页时，就产生了一个缺页故障，而这一页页必须从调页空间中读入到内存中。
po列：从内存交换到磁盘的交换页数量，4KB/页。如果窃取的工作也在调页空间中不存在或者已经作了修改，则写入调页空间中。如果不被再次访问，它会留在调度空间中直到进程终止或者放弃空间。
fr列：根据页面替换算法每秒释放的页数。当VMM页面替换例程扫描页面帧表（Page Frame Table，PFT）时，它会根据一些条件选取需要窃取的页面以补充空闲列表。该条件中包含工作页面和计算页面，释放的页面中，计算页面不产生I/O，工作页面如果数据没有发生修改，也不需要写回磁盘，也不会产生I/O。
sr列：根据页面替换算法每秒所检查的页数。sr值比fr值高的越多，说明替换算法要查找可以替换的页面就越困难。
cy列：每秒页面替换代码扫描了PFT多少次。因为增加空闲列表达到maxfree值，不一定需要完全扫描PFT表，而所有vmstat输出都为整数，所以通常cy列值为0。

Faults段显示内容（其实这段内容不需太多关注）
in列：在该时间间隔中观测到的每秒设备中断数。
sy列：在该时间间隔中观测到的每秒系统调用次数。
cs列：在该时间间隔中观测到的每秒钟上下文切换次数。

Cpu段显示内容
us列：显示了用户模式所消耗的 CPU 时间。
sy列：详细显示了 CPU 在系统模式所消耗的 CPU 时间。
id列：显示了没有未决本地磁盘 I/O 时 CPU 空闲或等待时间的百分比。
wa列：详细显示了有未决本地磁盘 I/O 时 CPU 空闲的时间百分比。wa 的值如果超过 25%,就表明磁盘子系统可能没有被正确平衡，或者这也可能是磁盘工作负荷很重的结果。
如果在一个单用户系统中，us + sy时间不超过 90%，我们就不认为系统的CPU是受限制的。
如果在一个多用户系统中，us + sy时间超过 80%, 我们就认为系统的CPU是受限的。其中的进程将要花时间在运行队列中等待。响应时间和吞吐量会受损害。
检查cpu，我们主要关注报告中的4个cpu列和2个kthr（内核线程）列。
在上面的示例中，我们可以观察到以下几个主要的信息：
CPU IDLE比较高，比较空闲；r列为0，表明线程不存在等待；
WA值不高，说明I/O压力不大；
free值比较大，pi，po为0，表明内存非常富裕。空闲较多。

--------------------------------------------------------------
Linux下获取占用CPU/内存资源最多的10个进程
1)获取占用CPU资源最多的10个进程，可以使用如下命令组合：
ps aux|head -1;ps aux|grep -v PID|sort -rn -k +3|head

2)获取占用内存资源最多的10个进程，可以使用如下命令组合：
ps aux|head -1;ps aux|grep -v PID|sort -rn -k +4|head
其中第一句主要是为了获取标题内容（即USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND这些内容），接下来的grep -v PID是将ps aux获得的结果去掉上面的标题，即grep不包含PID这三个字母组合的行，再将其中结果使用sort排序，sort -rn -k +3该命令中的-rn的r表示是结果倒序排列，n为以数值大小排序，而-k +3则是针对第3列的内容进行比对排序，再使用head命令获取默认前10行数据。(其中的|表示管道操作)

---------------------------------------------------------------
AIX:PS命令
1)显示10个消耗cpu最多的进程
ps aux |head -1 ;ps aux |sort -rn +2 |head -10

2)显示10个消耗内存最多的进程
ps vx |head -1 ;ps vx |grep -v PID |sort -rn +6 |head -10

3)显示10个换页最多的进程
ps vx |head -1 ;ps vx |grep -v PID |sort -rn +4 |head -10

4)显示10个消耗存储空间最多的进程
ps aux |head -1 ;ps aux |sort -rn +3 |head -10

----------------------------------------------------
AIX:svmon
# svmon -G
size inuse free pin virtual
memory 1048576 1048416 160 79327 137750
pg space 1048576 524

work pers clnt lpage
pin 79327 0 0 0
in use 137764 910652 0 0

其中的 size 列报告了 RAM 的大小，单位是大小为 4k 的页面。其中的 inuse 列报告了进程所使用的 RAM 中的页面数，加上属于一个已终止的进程但仍位于 RAM 中的持久页面的数目。其中的 free 列报告了空闲列表中页面的数目。其中的 pin 列报告了物理内存 (RAM) 中固定的页面数。固定的页面不能被调出。

paging space 列报告了分页空间的实际使用情况（单位是大小为 4k 的页面）。重要的是，应该清楚这个结果与 vmstat 所报告的结果之间的区别。vmstat 中的 avm 列显示了访问的所有虚拟内存，即使它没有被调出。我还习惯查看工作和持久页面的数目。这些参数显示了 RAM 中工作和持久页面的数目。这个内容为什么非常重要呢？也许您还记得第 1 部分中的内容，我曾介绍了工作和持久存储之间的区别。当您的进程对计算信息进行处理时，将使用到计算内存。它们使用工作段，而这些工作段是临时的（暂时的），并且当进程终止或者页面被替换时，这些工作段将不复存在。文件内存使用持久段，并在磁盘上具有持久的存储位置。数据文件或者可执行程序通常都映射为持久段，而不是工作段。在可以选择的情况下，您更希望将文件内存调出到磁盘，而不是计算内存。在这种情况下，与文件内存相比，计算内存更有可能被调出。也许，对 vmo 参数稍作优化就可以极大提高系统的性能。svmon 的另一个有价值的特性是，您可以显示给定进程的内存统计信息。清单 6 提供了一个示例。

清单 6. 使用 svmon 显示给定进程的内存统计信息

# svmon -P | grep -p 15256
-------------------------------------------------------------------------------
Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd LPage
15256 X 12102 3221 0 12022 N N N

从这个示例中，您可以确定该进程并没有使用分页空间。使用前面介绍过的 ps 命令，再加上 svmon，您就可以找出大量消耗内存资源的位置。

---------------------------------------------------------------
找到使用CPU资源异常的进程
比如说是ORACLE用户的ora_j00*进程，这是ORACLE的job进程。在这里，这些进程的开销很小。如果ORACLE的进程开销比较大，我们可以用如下的方法来查询具体的进程在干什么事情，例如我们要查询进程ora_j000_ora92，PID=344612，可以使用下面的方法：
$su – oracle
SQL>sqlplus “/as sysdba”
SQL>oradebug setospid 344612
SQL>oradebug event 10046 trace name context forever, level 8
SQL>oradebug tracefile_name –这个命令我们获得输出文件的绝对路径和文件名
SQL>oradebug event 10046 trace name context off
$tkprof /opt/oracle/app/oracle/admin/ora92/bdump/ora92_j000_344612.trc tracepid.txt
$more tracepid.txt
在tracepid.txt中，我们就可以看到这个进程中具体运行的语句、过程等，以及所有的SQL的cpu消耗、物理读、逻辑读、执行计划等信息。

另外，我们也可以执行下面的语句查看进程具体运行的SQL语句的文本：
SELECT /*+ ORDERED */ sql_text FROM v$sqltext a
WHERE (a.hash_value, a.address) IN (
SELECT DECODE (sql_hash_value,0, prev_hash_value,sql_hash_value),
DECODE (sql_hash_value,0, prev_sql_addr, sql_address)
FROM v$session b
WHERE b.paddr = (SELECT addr
FROM v$process c
WHERE c.spid = '&pid'))
ORDER BY piece ASC

--------------------------------------------------------------------------
iostat
1.关于磁盘的性能指标
在介绍磁盘 I/O 监控命令前，我们需要了解磁盘 I/O 性能监控的指标，以及每个指标的所揭示的磁盘某方面的性能。磁盘I/O 性能监控的指标主要包括：
1)每秒 I/O 数（IOPS 或 tps）
对于磁盘来说，一次磁盘的连续读或者连续写称为一次磁盘 I/O, 磁盘的 IOPS 就是每秒磁盘连续读次数和连续写次数之和。当传输小块不连续数据时，该指标有重要参考意义。
2)吞吐量（Throughput）
指硬盘传输数据流的速度，传输数据为读出数据和写入数据的和。其单位一般为 Kbps, MB/s 等。当传输大块不连续数据的数据，该指标有重要参考作用。
3)平均 I/O 数据尺寸
平均 I/O 数据尺寸为吞吐量除以 I/O 数目，该指标对揭示磁盘使用模式有重要意义。一般来说，如果平均 I/O 数据尺寸小于32K，可认为磁盘使用模式以随机存取为主；如果平均每次 I/O 数据尺寸大于 32K，可认为磁盘使用模式以顺序存取为主。
4)磁盘活动时间百分比（Utilization）%util
磁盘处于活动时间的百分比，即磁盘利用率，磁盘在数据传输和处理命令（如寻道）处于活动状态。磁盘利用率与资源争用程度成正比，与性能成反比。也就是说磁盘利用率越高，资源争用就越严重，性能也就越差，响应时间就越长。一般来说，如果磁盘利用率超过 70%，应用进程将花费较长的时间等待 I/O 完成，因为绝大多数进程在等待过程中将被阻塞或休眠。
5)服务时间（ServiceTime）svctm
指磁盘读或写操作执行的时间，包括寻道，旋转时延，和数据传输等时间。其大小一般和磁盘性能有关，CPU/ 内存的负荷也会对其有影响，请求过多也会间接导致服务时间的增加。如果该值持续超过 20ms，一般可考虑会对上层应用产生影响。
6)I/O 等待队列长度（Queue Length）
指待处理的 I/O 请求的数目，如果 I/O 请求压力持续超出磁盘处理能力，该值将增加。如果单块磁盘的队列长度持续超过2，一般认为该磁盘存在 I/O 性能问题。需要注意的是，如果该磁盘为磁盘阵列虚拟的逻辑驱动器，需要再将该值除以组成这个逻辑驱动器的实际物理磁盘数目，以获得平均单块硬盘的 I/O 等待队列长度。
7)等待时间（Wait Time）
指磁盘读或写操作等待执行的时间，即在队列中排队的时间。如果 I/O 请求持续超出磁盘处理能力，意味着来不及处理的I/O 请求不得不在队列中等待较长时间。通过监控以上指标，并将这些指标数值与历史数据，经验数据以及磁盘标称值对比，必要时结合 CPU、内存、交换分区的使用状况，不难发现磁盘 I/O潜在或已经出现的问题。但如果避免和解决这些问题呢？这就需要利用到磁盘 I/O 性能优化方面的知识和技术。限于本文主题和篇幅，仅列出一些常用的优化方法供读者参考：
（1）调整数据布局，尽量将 I/O 请求较合理的分配到所有物理磁盘中；
（2）对于 RAID 磁盘阵列，尽量使应用程序 I/O 等于条带尺寸或者为条带尺寸的倍数。并选取合适的 RAID 方式，如RAID10，RAID5；
（3）增大磁盘驱动程序的队列深度，但不要超过磁盘的处理能力，否则，部分 I/O 请求会因为丢失而重新发出，这将降低性能；
（4）应用缓存技术减少应用存取磁盘的次数，缓存技术可应用在文件系统级别或者应用程序级别；
（5）由于多数数据库中已包括经优化后的缓存技术，数据库 I/O 宜直接存取原始磁盘分区（rawpartition）或者利用绕过文件系统缓存的 DIO 技术（direct IO）；
（6）利用内存读写带宽远比直接磁盘 I/O 操作性能优越的特点，将频繁访问的文件或数据置于内存中。

#iostat 1 3

System configuration: lcpu=16 drives=11 paths=4 vdisks=0

tty: tin tout avg-cpu: % user % sys % idle % iowait
0.0 59.7 30.4 17.0 25.6 27.1

Disks: % tm_act Kbps tps Kb_read Kb_wrtn
hdisk1 1.0 4.0 1.0 0 4
hdisk0 0.0 4.0 1.0 0 4
hdisk2 0.0 0.0 0.0 0 0
hdisk3 0.0 0.0 0.0 0 0
dac0 0.0 14477.7 1513.4 3072 11469
dac0-utm 0.0 0.0 0.0 0 0
dac1 0.0 0.0 0.0 0 0
dac1-utm 0.0 0.0 0.0 0 0
hdisk4 74.7 4968.3 440.1 1728 3262
hdisk5 99.6 9508.4 1073.3 1344 8206
cd0 0.0 0.0 0.0 0 0

下面对输出的结果说明如下：
--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 选项会显示这些信息。

扩展指标介绍：
参数 英文说明 说明

rrqm/s read request merge 每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s write request merge 每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s read 每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s write 每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s read section 每秒读扇区数。即 delta(rsect)/s
wsec/s write section 每秒写扇区数。即 delta(wsect)/s
rkB/s read kilo byte 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)
wkB/s write kilo byte 每秒写K字节数。是 wsect/s 的一半。(需要计算)
avgrq-sz average request size 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz average queue size 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)
await average wait 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm service time 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util utilty 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)

如果%util接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈，idle小于70% IO压力就较大了,一般读取速度有较多的wait。同时可以结合vmstat（virtual memory status）查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)

另外还可以参考svctm，由于它一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会间接导致svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。

例子(I/O 系统 vs. 超市排队)
举一个例子，我们在超市排队 checkout 时，怎么决定该去哪个交款台呢? 首当是看排的队人数，5个人总比20人要快吧? 除了数人头，我们也常常看看前面人购买的东西多少，如果前面有个采购了一星期食品的大妈，那么可以考虑换个队排了。还有就是收银员的速度了，如果碰上了连钱都点不清楚的新手，那就有的等了。另外，时机也很重要，可能 5 分钟前还人满为患的收款台，现在已是人去楼空，这时候交款可是很爽啊，当然，前提是那过去的 5 分钟里所做的事情比排队要有意义(不过我还没发现什么事情比排队还无聊的)。

I/O 系统也和超市排队有很多类似之处:

r/s+w/s 类似于交款人的总数

平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数

平均服务时间(svctm)类似于收银员的收款速度

平均等待时间(await)类似于平均每人的等待时间

平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少

I/O 操作率(%util)类似于收款台前有人排队的时间比例。

#iostat -x 1

avg-cpu: %user %nice %sys %idle

16.24 0.00 4.31 79.44

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

sda 0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29

上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作:

总IO(io)/s=r/s(读)+w/s(写)=1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)

平均每次设备I/O操作只需要5ms就可以完成，但每个I/O请求却需要等上78ms，为什么? 因为发出的 I/O 请求太多 (每秒钟约29个)，假设这些请求是同时发出的，那么平均等待时间可以这样计算:

平均等待时间=单个I/O服务时间* ( 1 + 2 + … + 请求总数-1) /请求总数

应用到上面的例子: 平均等待时间 = 5ms * (1+2+…+28)/29 = 70ms，和 iostat 给出的78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。

每秒发出的 I/O 请求很多 (约29个)，平均队列却不长 (只有2个左右)，这表明这 29 个请求的到来并不均匀，大部分时间 I/O是空闲的。

一秒中有 14.29% 的时间 I/O 队列中是有请求的，也就是说，85.71% 的时间里 I/O 系统无事可做，所有 29 个 I/O 请求都在142毫秒之内处理掉了。

delta(ruse+wuse)/delta(io)= await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 =2232.8，表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为2232.8ms/1000ms = 2.23，而 iostat 给出的平均队列长度(avgqu-sz) 却为 22.35，为什么?! 因为 iostat 中有 bug，avgqu-sz 值应为 2.23，而不是 22.35。

我们可以根据这些数据分析出 I/O 请求的模式，以及 I/O 的速度和响应时间。

----------------------------------------------------------------------------------------------------------
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的方式比较好。