解读 iostat -mxd 1
####
for AWR 报告 ：
建议如下：
不能随便调整db_file_multiblock_read_count 值，
取同样时间段的AWR 报告 02:00 ~ 05:00，所以db_file_multiblock_read_count 的值不能随便调整，从48 调整大到 128，发现 avg time 从 6 秒 调大 到 22 秒。
db_file_multiblock_read_count 48
=Wait Avg(ms) 6
db_file_multiblock_read_count 128
= Wait Avg(ms) 22
##########sample 0
linux block 大小为1M.
# time dd if=/dev/sdak bs=1024k of=/dev/null iflag=direct
写
dd if=/dev/zero of=kwxgd bs=64k count=4k oflag=dsync
读
dd if=kwxgd of=/dev/zero bs=64k count=4k iflag=direct
正常 50M左右 性能比较好
在第一个图中，我们只写1块，然后使用oflag=sync与conv=fsync 测出来一个是32.1kb/s 一个是37.8kb/s 差别不大。但是下一个我写1000个，conv=fsync就明显的比oflag=dsync/sync快很多了，所以觉得上面自己扣的英文的理解应该是正确的。
所以在用dd做读或者写的时候，应该要注意自己的使用场景，如果需要将数据写入磁盘的话
dd if=/dev/zero of=test bs=64k count=16k 是不准确的，
如何真正写磁盘
dd if=/dev/zero of=test bs=64k count=16k 这个是不准确的，因为命令结束的时候数据还没有真正写到磁盘上去，因为对磁盘的写，我们一般是先写到了缓存就返回了。
我们来看dd的帮助页面对于一些参数的解释
the FLAG 参数（完整的看手册哦，这里假设你是知道iflag跟oflag的）
-dsync
Use synchronized I/O for data. For the output file, this forces a physical write of output data on each write. For the input file, this flag can matter when reading from a remote file that has been written to synchronously by some other process. Metadata (e.g., last-access and last-modified time) is not necessarily synchronized.
-sync likewise, but also for metadata
the CONV参数
-fsync
Synchronize output data and metadata just before finishing. This forces a physical write of output data and metadata
dsync跟sync比较好理解，前者是只同步写数据，sync同时写元数据
但是感觉dsync与 -fsync怎么感觉有些一样？ 网上的说法是 dd if=/dev/zero of=test bs=64k count=4k oflag=dsync 这个可以当成是模拟数据库插入操作，所以很慢，但还是没太明白。
后来自己认真的抠了这英文用词， conv=fsync Synchronize output data and metadata just before finishing 意思也就是在dd命令结束前同步data和metadata，那就是不是每一次写都同步一次咯，也就是如果我们在dd命令中写了100次，他可能是等到最后的时候才把他们同步到磁盘。而oflag=dsync是说Use synchronized I/O for data. For the output file, this forces a physical write of output data on each write，注意这里边用词 a physical write of output data on each write,那就是他是每一次写都得等到这一次写写到了磁盘才进行下一个写，也就是如果我们使用dd写100次，他每次写都是写到磁盘后才进行下一次写的。所以这样当然要比conv=fsync慢一些吧。那么自己感觉如果只是写一次的话，两者应该是差别不大的，后来做了下小实验，证实确实是这样的。
而 dd if=/dev/zero of=test bs=64k count=16k conv=fsync 比较准备，他在dd结束前会写到磁盘，
而dd if=/dev/zero of=test bs=64k count=4k oflag=dsync或者sync 是真正的每写一次就写一次磁盘，所以其实可以听到磁盘啪啪啪的响的。
##########sample 1
At the same time:
$ iostat -mx dm-10 10 ( 建议使用这个方法查看 iostat -dmx 1 ， rMB/s wMB/s ，svctm， r/s w/s )
...
avg-cpu: %user %nice %system %iowait %steal %idle
11.97 0.00 1.79 12.21 0.00 74.03
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sdak 0.00 0.00 800.00 0.00 200.00 0.00 512.00 1.77 2.22 0.60 47.86
平均单次IO大小(IO Chunk Size) avgrq-sz 512-sector chunks ,每个chunk size 为512k, 每秒一共(1/ 0.002)= 400K 个chunks, （0.002 取自await 时间）
每秒 800 次读，每秒200M,
* I.e. – as per iostat the 1024KB operations are being split into 512-sector chunks (i.e. into 256KB). Same happens with 512KB requests too.
* 256KB and smaller don’t seem to be split in that way.
* 8MB -> split to 256KB
* 20000MB -> split into ~500KB avg request size. (So seems it can do more than 256K sometimes…)
平均单次IO大小(IO Chunk Size) avgrq-sz
平均IO响应时间(IO Response Time) await
IOPS(IO per Second) r/s + w/s
吞吐率(Throughtput) rkB/s + wkB/s
Oracle ORION 下载
http://www.oracle.com/technetwork/cn/topics/index-088165-zhs.html
http://www.jydba.net/oracle-orion-calibration-tool/
(important)
####sampe 2:
## iostat -dmx 1
root@temc_vcs01 dev]# vxprint -g temcdg
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0
dg temcdg temcdg - - - - - -
dm eerd04 eerd - 146729872 - - - -
dm eerd05 eere - 146729872 - - - -
dm eerd06 eerf - 146729872 - - - -
dm eerd07 eerg - 146729872 - - - -
dm eerd08 eerh - 419348128 - - - -
dm temcdisk01 eera - 209643136 - - - -
dm temcdisk02 eerb - 419348128 - - - -
dm temcdisk03 eerc - 419348128 - - - -
v archiveloglv fsgen ENABLED 104857600 - ACTIVE - -
pl archiveloglv-01 archiveloglv ENABLED 104857600 - ACTIVE - -
sd temcdisk02-01 archiveloglv-01 ENABLED 104857600 0 - - -
v oracleapplv fsgen ENABLED 31457280 - ACTIVE - -
pl oracleapplv-01 oracleapplv ENABLED 31457280 - ACTIVE - -
sd temcdisk01-01 oracleapplv-01 ENABLED 31457280 0 - - -
v oracledatalv fsgen ENABLED 1614807040 - ACTIVE - -
pl oracledatalv-01 oracledatalv ENABLED 1614807040 - ACTIVE - -
sd temcdisk02-02 oracledatalv-01 ENABLED 209797472 0 - - -
sd temcdisk03-01 oracledatalv-01 ENABLED 419348128 209797472 - - -
sd temcdisk01-02 oracledatalv-01 ENABLED 178185856 629145600 - - -
sd temcdisk02-03 oracledatalv-01 ENABLED 52642400 807331456 - - -
sd eerd04-01 oracledatalv-01 ENABLED 146729872 859973856 - - -
sd eerd05-01 oracledatalv-01 ENABLED 146729872 1006703728 - - -
sd temcdisk02-04 oracledatalv-01 ENABLED 52050656 1153433600 - - -
sd eerd08-01 oracledatalv-01 ENABLED 409322784 1205484256 - - -
[root@temc_vcs01 dev]#
[root@temc_vcs01 dev]#
[root@temc_vcs01 dev]#
[root@temc_vcs01 dev]#
[root@temc_vcs01 dev]#
[root@temc_vcs01 dev]# pwd
vi ptest.lun
/dev/eera
/dev/eerb
/dev/eerc
/dev/eerd
/dev/eere
/dev/eerf
/dev/eerg
/dev/eerh
[root@temc_vcs01 dev]# dd if=/dev/eerc of=/dev/null bs=8129 count=1024
1024+0 records in
1024+0 records out
Orion命令行示例
1.对于OLTP数据库来评估存储的IO性能 （IOPS通道）
system 1: vcfs : 8个盘加起来，IOPS=12190 ，平均每个盘1300左右
./orion -run oltp -testname ptest
[root@temc_vcs01 orion]# ./orion -run oltp -testname ptest
ORION: ORacle IO Numbers -- Version 11.1.0.7.0
ptest_20171225_2324
Test will take approximately 29 minutes
Larger caches may take longer
[root@temc_vcs01 round1]# more *summ*
ORION VERSION 11.1.0.7.0
Commandline:
-run oltp -testname ptest
This maps to this test:
Test: ptest
Small IO size: 8 KB
Large IO size: 1024 KB
IO Types: Small Random IOs, Large Random IOs
Simulated Array Type: CONCAT
Write: 0%
Cache Size: Not Entered
Duration for each Data Point: 60 seconds
Small Columns:, 8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 88, 96,
104, 112, 120, 128, 136, 144, 152, 160
Large Columns:, 0
Total Data Points: 28
Name: /dev/eera Size: 107374510080
Name: /dev/eerb Size: 214749020160
Name: /dev/eerc Size: 214749020160
Name: /dev/eerd Size: 75162255360
Name: /dev/eere Size: 75162255360
Name: /dev/eerf Size: 75162255360
Name: /dev/eerg Size: 75162255360
Name: /dev/eerh Size: 214749020160
8 FILEs found.
Maximum Small IOPS=12190 @ Small=160 and Large=0
Minimum Small Latency=7.47 @ Small=8 and Large=0
---system 2 vmware vg00 4个盘加起来，IOPS=5190 ，平均每个盘1300左右
[root@pisa orion]# more *summary*
ORION VERSION 11.1.0.7.0
Commandline:
-run oltp -testname ptest
This maps to this test:
Test: ptest
Small IO size: 8 KB
Large IO size: 1024 KB
IO Types: Small Random IOs, Large Random IOs
Simulated Array Type: CONCAT
Write: 0%
Cache Size: Not Entered
Duration for each Data Point: 60 seconds
Small Columns:, 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56,
60, 64, 68, 72, 76, 80
Large Columns:, 0
Total Data Points: 24
Name: /dev/sda3 Size: 29956469760
Name: /dev/sda4 Size: 53686402560
Name: /dev/sdb Size: 107374182400
Name: /dev/sdc Size: 858993459200
4 FILEs found.
Maximum Small IOPS=5363 @ Small=68 and Large=0
Minimum Small Latency=6.07 @ Small=4 and Large=0
2.对于DSS数据库评估存储IO性能 (测试存储通道宽)
./orion -run dss -testname ptest &
##system 1 vcfs 0.218 8个盘加起来，MBPS=772.00 ，平均每个盘98M
[root@temc_vcs01 round2]# more *su*
ORION VERSION 11.1.0.7.0
Commandline:
-run dss -testname ptest
This maps to this test:
Test: ptest
Small IO size: 8 KB
Large IO size: 1024 KB
IO Types: Small Random IOs, Large Random IOs
Simulated Array Type: CONCAT
Write: 0%
Cache Size: Not Entered
Duration for each Data Point: 240 seconds
Small Columns:, 0
Large Columns:, 8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 88, 96,
104, 112, 120
Total Data Points: 23
Name: /dev/eera Size: 107374510080
Name: /dev/eerb Size: 214749020160
Name: /dev/eerc Size: 214749020160
Name: /dev/eerd Size: 75162255360
Name: /dev/eere Size: 75162255360
Name: /dev/eerf Size: 75162255360
Name: /dev/eerg Size: 75162255360
Name: /dev/eerh Size: 214749020160
8 FILEs found.
Maximum Large MBPS=772.00 @ Small=0 and Large=72
####system 2 local
This maps to this test: 4个盘加起来，MBPS=400.00 ，平均每个盘100M
Test: ptest
Small IO size: 8 KB
Large IO size: 1024 KB
IO Types: Small Random IOs, Large Random IOs
Simulated Array Type: CONCAT
Write: 0%
Cache Size: Not Entered
Duration for each Data Point: 240 seconds
Small Columns:, 0
Large Columns:, 4, 8, 12, 16, 20, 24, 28, 32,
36, 40, 44, 48, 52, 56, 60
Total Data Points: 19
Name: /dev/sda3 Size: 29956469760
Name: /dev/sda4 Size: 53686402560
Name: /dev/sdb Size: 107374182400
Name: /dev/sdc Size: 858993459200
4 FILEs found.
Maximum Large MBPS=438.48 @ Small=0 and Large=32
3.对于基本的数据集评估存储IO性能
./orion -run normal -testname jytest
4.为了理解存储性能使用只读，小与大的随机I/O工作量:
/orion -run simple -testname jytest
3..为了理解存储性能使用小与大混合的随机I/O工作量:
http://blog.csdn.net/haiross/article/details/43196731?locationNum=9&fps=1
(important)
########SAMPLE 3:
|
$iostat -x 1 Linux 2.6.33-fukai (fukai-laptop) _i686_ (2 CPU) avg-cpu: %user %nice %system %iowait %steal %idle
5.47 0.50 8.96 48.26 0.00 36.82
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 6.00 273.00 99.00 7.00 2240.00 2240.00 42.26 1.12 10.57 7.96 84.40
sdb 0.00 4.00 0.00 350.00 0.00 2068.00 5.91 0.55 1.58 0.54 18.80
rrqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s: 每秒读扇区数。即 delta(rsect)/s
wsec/s: 每秒写扇区数。即 delta(wsect)/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)
wkB/s: 每秒写K字节数。是 wsect/s 的一半。(需要计算)
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)
如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘
可能存在瓶颈。
idle小于70% IO压力就较大了,一般读取速度有较多的wait.
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
另外 await 的参数也要多和 svctm 来参考。差的过高就一定有 IO 的问题。
avgqu-sz 也是个做 IO 调优时需要注意的地方，这个就是直接每次操作的数据的大小，如果次数多，但数据拿的小的话，其实 IO 也会很小.如果数据拿的大，才IO 的数据会高。也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲，读定速度是这个来决定的。
###########SAMPLE 4
下面是别人写的这个参数输出的分析
# iostat -DMx 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
/dev/cciss/c0d0 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。
https://sort.veritas.com/patch/detail/8260
https://www.cnblogs.com/ch3n3y/p/5930605.html (dmesg -c)
http://blog.itpub.net/23718752/viewspace-1246724
http://blog.csdn.net/t0nsha/article/details/22905433
http://blog.csdn.net/hayyon/article/details/246666
http://blog.csdn.net/yangzhenzhen/article/details/39078277
平均单次IO大小(IO Chunk Size)
