oracle orion测试工具的使用

ORION是Oracle提供的IO测试工具，这个工具可以在不安装Oracle软件的情况下模拟Oracle的IO操作，从而可以预估部署数据库之后的系统性能。

可以到oracle的官方网站上下载使用

wget http://download.oracle.com/otn/utilities_drivers/orion/orion_linux_x86-64.gz?AuthParam=1497505586_52e042e7685f5f74a0f82352ae57a853

使用guzip 解压

[root@WebServer ~]# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cciss/c0d0p3     24697068   4539148  18883124  20% /
/dev/cciss/c0d1p1    247939448    975300 234166372   1% /oracle
/dev/cciss/c0d2p1    277699124  42386596 220978536  17% /home
/dev/cciss/c0d0p1        98747     11899     81749  13% /boot
tmpfs                  2023132         0   2023132   0% /dev/shm

创建需要检测的磁盘目录

vi case1

/dev/cciss/c0d0p3    
/dev/cciss/c0d1p1    
/dev/cciss/c0d2p1    
/dev/cciss/c0d0p1

运行命令

[root@WebServer ~]# /root/orion_linux_x86-64 -run simple -testname case1 -num_disks 6
ORION: ORacle IO Numbers -- Version 11.1.0.7.0
case1_20130222_1436
Test will take approximately 44 minutes
Larger caches may take longer

得到五个文件

-rw-r--r-- 1 root root             41299 Feb 22 15:18 case1_20130222_1436_trace.txt
-rw-r--r-- 1 root root               802 Feb 22 15:18 case1_20130222_1436_summary.txt
-rw-r--r-- 1 root root               500 Feb 22 15:18 case1_20130222_1436_mbps.csv
-rw-r--r-- 1 root root               648 Feb 22 15:18 case1_20130222_1436_lat.csv
-rw-r--r-- 1 root root               648 Feb 22 15:18 case1_20130222_1436_iops.csv

都是csv的格式

可以绘制成图片

 

 

Orion是oracle提供的测试io性能的工具。它可以用来模拟Oracle数据库IO，也可以用来仿
真ASM的条带化的功能。

Orion可以支持下列IO负载

1. 小的随机的IO：OLTP的应用主要是随机的读写，大小和数据的块大小一样（一般是8K）。这样的应用主要是关注的吞吐量是IOPS和一个请求的平均延时时间。Orion可以仿真一个随机IO负载。指定的读写百分比，指定的IO大小，指定的IOs，IOs是分布在不同的磁盘上。

2. 大的连续的IO：数据仓库的应用，数据装载，备份，和恢复会产生连续的读写流，这些读写是由多个1M的IO组成的。这些应用都是处理大数据量的数据，主要是关注总体的数据吞吐量MBPS

3. 大的随机的IO: 一个连续的读写和其他的数据库活动同时访问磁盘。基于条带化，一个连续的读写扩展到多个磁盘上。因此，在磁盘的这个层次上，许多的连续的读写被看作随机的1M的IO,又被称作多用户的连续IO。

4. 混合的负载: Orion可以同时仿真前俩种负载：小的随机的IO，大的连续的IO。这将使你
可以仿真，OLTP的8K的随机读写的负载和4个连续的1M IO读写的备份的负载。

针对不同的IO负载，Orion可以在不同的IO压力测试并得到性能参数：MBPS，IOPS，和IO延迟时间。负载是术语，代表异步的IOs的数目。内部本质来说，每一个负载层次，Orion软件一直在尽快的发I/O请求来完成这个层次的I/O负载。针对随机的负载（大的和小的），负载的层次就是I/Os的数目。针对大的连续的负载，负载的层次就是连续的读写流和每次读写流的IO的数目。在负载层次范围内测试指定的负载将帮助用户理解性能是怎么受影响的。

测试目标：

理论上，ORION可以用来测试任何支持异步的字符设备。ORION已经在下列类型的设备上测试过。

1. DAS(directed_attatched)的存储：
2. SAN(storage-area network)的存储：
3. ORION没有在NAS(network-attached storage).

ORION对存储设备的供应商：
供应商可以用ORION来理解Oracle是如何来在存储上执行的。也可以用Orion来找出适合Oracle最好的存储配置。

ORION对Oracle管理员
Oracle管理员可以根据期望的工作量使用Orion来评估和比较不同的存储阵列。他们也可以用Orion来决定峰值时优化的网络连接数，存储阵列数，存储阵列控制器数，和磁盘数。附录A描述了根据数据库现在的工作量来推测IOPS和MBPS需求。

开始使用Orion
1. 下载orion: 有Linux/x86，Solaris/SPARC 和Windows/x86版本
2. 安装Orion
Linux/Solaris：解压Orion执行文件。
gunzip orion_linux_x86-64.giz
Windows: 运行安装程序
C:\temp> orion_windows_x86-64.msi

3. 选择测试名，我们使用的名是mytest

4. 创建文件名 mytest.lun，例如：
/dev/raw/raw1
/dev/raw/raw2
...
/dev/raw/raw8

5. 验证设备是不是可以访问。Linux可以用下面的命令：
$ dd if=/dev/raw/raw1 f=/dev/null bs=32k count=1024
1024+0 records in
1024+0 records out

6. 验证在你的平台上已经有异步IO的类库。Orion测试完全是依赖异步的IO。在linux和solaris，类库libaio需要安装并被访问。环境变量名是LD_LIBRARY_PATH或者是LIBPATH,window已经安装异步IO。

7. 第一次测试，建议使用simple，simple测试衡量在不同的负载下的小随机读和大的随机读。这些结果给我一些想法，不同类型的IO和负载下的IO性能。simple测试的命令：

./orion_linux_x86-64 -run simple -testname mytest -num_disks 4

ORION: ORacle IO Numbers -- Version 11.1.0.7.0
mytest_20101218_2205
Test will take approximately 30 minutes
Larger caches may take longer

Orion生成的IO负载层次考虑了在mytest.lun文件中磁盘的数目。

8. 结果将被记录在输出文件中。

输出文件：

Orion将产生几个输出文件,

1. mytest_summary.txt: 这个文件包含：
a. 输入参数
b. 针对大的随机和连续的工作量下观察到的最大的吞吐量
c. 针对小的随机的工作量的IO速率
d. 针对小的随机的工作量的最小的延迟时间。

[root@dbs101 software]# more mytest_20101218_2205_summary.txt
ORION VERSION 11.1.0.7.0

Commandline:
-run simple -testname mytest -num_disks 4

This maps to this test:
Test: mytest
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:, 0
Large Columns:, 0, 1, 2, 3, 4, 5, 6, 7, 8
Total Data Points: 29

Name: /dev/sda5 Size: 102404703744
Name: /dev/sdb1 Size: 102404703744
Name: /dev/sdc1 Size: 102404703744
Name: /dev/sdd1 Size: 102404703744
4 FILEs found.

Maximum Large MBPS=62.80 @ Small=0 and Large=7
Maximum Small IOPS=647 @ Small=20 and Large=0
Minimum Small Latency=7.32 @ Small=1 and Large=0

2. mytest_mbps.csv文件：这是个csv文件。包含大的随机或者连续的IO工作量。所有的csv输出文件有个2维表。行代表大的IO负载层次。列代表小的IO负载层次。simple测试不包含大的和小的IO结合。所以MBPS文件只有一个列，0代表没有小的IO。

# more mytest_20101218_2205_mbps.csv
Large/Small, 0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 20
1, 35.27
2, 49.03
3, 55.23
4, 58.20
5, 60.33
6, 60.34
7, 62.80
8, 62.44

在这个例子中，当负载层次在5的时候，没有小的IO操作，我们得到的数据吞吐量是60.33MBPS，我们可以用excel图形来显示MBPS的速率。

test_20101218_2205_mbps.csv
Large/Small, 0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 20
3. mytest_iops.csv: 这是个小的随机的IO工作量的IOPS吞吐量。

4. mytest_lat.csv: 这是个小的随机的IO工作量下的延迟时间。

# more mytest_20101218_2205_lat.csv
Large/Small, 1, 2, 3, 4, 5, 6, 7, 8,
9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
19, 20
0, 7.32, 8.63, 9.93, 11.15, 12.31, 13.38, 14.59, 15.71, 16
.83, 18.23, 19.36, 20.45, 21.77, 23.02, 24.43, 25.73, 27.16, 28.23, 29
.57, 30.87
1
2
3
4
5
6
7
8

5. mytest_trace.txt: 包含扩展的，未处理的测试输出。

输入参数：Orion可以使用命令的参数来测试任意一种工作量。强制输入的参数：

run：测试运行的层次，这个选项提供simple，normal，advanced的层次。如果没有指定advanced，那么设置有些非强制的参数（-cache_size和-verbose）将会出错。
simple：产生小的随机的IO和大的连续的IO工作量。在这个选项中，小的随机的IO和 大的连续的IO是分开测试的。这个参数对应下列的Orion调用：
./orion -run advanced -testname mytest \
-num_disks 4 \
-size_small 8 -size_large 1024 -type rand \
-simulate concat -write 0 -duragion 60 \
-matrix basic

normal: 除了simple的功能外，还会产生小的随机的IO和大的连续的IO的结合。
./orion -run advanced -testname mytest \
-num_disks 4 \
-size_small 8 -size_large 1024 -type rand \
-simulate concat -write 0 -duragion 60 \
-matrix detailed

advanced: 如果用这个选项，用户需要指定可选的参数。

testname: 输入文件必须是<testname>.lun

num_disks: 实际测试的物理磁盘的数目。

可选的输入参数：

help：帮助信息

size_small: 小的随机工作量的IO的大小（KB）

size_large: 大的随机的或者连续工作量的大小（KB）。

type：大的IO的工作量（默认是rand）：
rand：大的随机的IO
seq：大的连续的IO

num_streamIO: 每个大的连续读写流的IO数目。只是在-type seq下使用。

simulate：大的连续的IO工作量小的数据分布。

contact：串联指定的luns成一个虚拟的卷。在虚拟的卷上的连续的测试从某个点到一个 lun的结束点。然后再到下一个lun。

raid0：在指定的luns上条带化成一个虚拟的卷。条带的大小是1M（和asm的条带大小一 致），可以通过参数-stripe来更改。

write: 和读相比的写的百分比，这个参数在小的随机的和大的连续的IO工作量下适用。在大的连续的IO，每个读写流要么是读要么是写。这个参数是指只是写百分比。写的数据都是垃圾数据。 写的测试将破坏的指定的lun。

cache_size: 存储阵列的读写缓存大小（MB）。针对大的连续的IO工作量，Orion将在每个测试点之前warm的cache。使用缓存大小来决定缓存操作。如果没有指定，将有个默认值。如果是0的话，将没有warm缓存。

duration: 每个测试点的时间。（默认是60）

matrix: 混合工作量测试的类型
basic：没有混合的工作量，小的随机的IO和大的连续的IO分开测试。
detailed：小的随机的IO和大的连续的IO结合起来测试。
point: 单个测试点，S代表小的随机的IO，L代表大的随机/连续的IO。

S -num_small L -num_large
col: 大的随机/连续的IO
row： 小的随机的IO
max：和detailed一样，只是在最大的负载下测试工作量。可以用-num_small和
-num_large参数指定。

num_small: 小的随机的IO的最大数目。
num_large: 大的随机的IO或者一个读写流的并发数目。

verbose：打印进度和状态到控制台。

命令行例子：
为了理解你的存储性能，小的随机读和大的随机IO读工作量，先开始运行：
./orion -run simple -num_disks 4 -testname mytest

测试小的随机读和大的随机读的IO工作量，运行：
./orion -run normal -testname mytest -num_disks 4

测试32K和1MB随机读的组合
./orion -run advanced -testname mytest -num_disks 4 -size_small 32 \
-size_large 1024 -type rand -matrix detailed

测试1MB连续写流，仿真1MB的raid-0条带化
./orion -run advanced -testname mytest -num_disk 4 -simulate raid0 \
-stripe 1024 -write 100 -type seq -matrix col -num_small 0

常见问题：

在<testname>.lun中的卷发生IO错误：
用dd拷贝文件命令来验证
验证操作系统支持异步IO
在linux和solaris中， 类库libaio必须在类库路径中

如果使用的是NAS
确保文件系统被加载
<testname>.lun的文件要包含一个或多个已有文件，Orion不和目录或加载点工
作。文件要足够大，能代表你实际数据文件大小。
NFS在linux下异步IO性能很差， 如果测试的时候遇到没有初始化的或者未写过的块的时候，有些智能的NAS系统将产生伪造的数据，解决方法是写所有的块。

如果在windows下测试
在裸设备上测试的时候，要映射一个盘符

如果是运行32位Orion在64位Linux上
拷贝一份32位的libaio到64位机器上

如果测试的磁盘数超过30
你应该使用duration参数，并为每个测试点制定一个更长的时间（120秒）。因
为Orion让所有的轴都运行在一个负载下。每个测试点需要加大时间。
你可能遇到下列的错误
specify a longer -duration value.

类库的错误
参考第一个常见错误
NT-ONLY：确保oracle的类库和orion在同一个目录

遇到”unbelievably good"
可能有个很大读写缓存，一般存储阵列控制器有很大的影响。找出缓存的大小，
并在参数-cache_size中为orion指定。
卷的大小不够，尝试关闭缓存。如果其他卷共享存储，将会看到突出的IO操作。

Orion报告长时间运行
如果num_disks高的话，运行时间也很长。
参数cache_size影响运行时间，Orion为每个测试点准备缓存需要2分钟。 如
果你关闭了你的缓存，你可以指定参数cache_size=0
如果指定的参数duration很长，运行时间是很长。

附录A：分类数据库的IO负载

为了正确的配置数据库的存储设备，必须了解数据库的性能需求。

1 IO请求主要是单个块还是多个块
数据库将发出多个IO请求：并行查询，查询大数据量的表扫描，直接数据装
载，备份恢复。一般来说，OLTP主要是单个IO请求，DSS数据仓库是多个IO请
求。
2 平均和峰值的IOPS是多少? 写占多少百分比。
3 平均和峰值的MBPS是多少？写占多少百分比。

如果你的数据库IO请求主要是单个块，那就关注IOPS，如果数据库IO请求主要是多个
块，那就关注MBPS。

10gR2数据库：可以从视图v$sysstat得到IO的类型。
单个数据块的读："physical read total IO requests" - "physical read
total multi block requests"
多个数据块的读："physical read total multi block requests"
读的总和："physical read total IO requests"
单个数据块的写："physical write total IO requests" - "physical write
total multi block requests"
多个数据块的写："physical write total multi block requests"
写的总和："physical write total IO requests"

使用这些数据，你可以评估在一段时间范围内（包含正常时间和峰值时间）读写的
IOPS和MBPS，

select name, value
from v$sysstat
where name in ('physical read total IO requests',
'physical read total multi block requests',
'physical write total IO requests',
'physical write total multi block requests');

NAME VALUE
physical read total IO requests 2068290092
physical read total multi block requests 2255995
physical write total IO requests 9968770
physical write total multi block requests 251551

单个数据块读是98%
单个数据块写实97%

也可以从awr报表中得到这些数据。
Instance Activity Stats DB/Inst: DBS108A/dbs108a Snaps: 8881-8882

-> Ordered by statistic name

Statistic Total per Second per Trans
-------------------------------- ------------------ -------------- -------------
...
physical read total IO requests 27,791 15.7 38.7
physical read total bytes 319,881,216 180,368.5 444,897.4
physical read total multi block 115 0.1 0.2
...
physical write total IO requests 4,278 2.4 6.0
physical write total bytes 49,528,320 27,927.1 68,885.0
physical write total multi block 22 0.0 0.0

附录B：数据仓库
在数据仓库设计和管理的时候，IO性能是一个关键的部分，典型的数据仓库系统是
IO集中，操作在大数据量上，数据加载，重建索引和创建物化视图。数据仓库支持
的IO必须设计符合过度的需求。

数据仓库的存储配置是根据IO带宽，而不是总的容量。磁盘的容量比磁盘吞吐量速
率发展快，结果少数几个磁盘可以存储大量的数据。但是大量的磁盘不能提供同样
IO吞吐量。你可以用多个磁盘和管道来得到最大的带宽。条带化是一种方法来实现。
实现一个大的条带大小（1M）来确保时间来定位磁盘和传输数据。

orion可以仿真连续的IO吞吐量，例如：
白天的工作量：当终端客户，其他应用查询系统：许多单独的并发只读IO
数据装载：终端用户可能访问数据库，写的工作量和一些可能并行读（也许是
装载程序或者终端用户）
重建索引和物化视图：读写工作量
备份：只读的工作量，可能高的并行度

使用下列选项来仿真不同的数据仓库的工作量

run：使用advanced来仿真只读连续的IO
large：大的连续读的IO大小。这个参数是os io大小的整数倍。
type： 使用seq
num_streamIO: 增加这个参数来仿真并行执行操作。指定计划的并行度。一个
好的开始点是CPU数目*一个CPU的线程数。
simulate：如果使用硬件条带化或者卷管理器条带化，则使用concat。如果还
没有条带化，比如ASM，则使用raid0。默认条带大小是1M。
write：写占用的百分比。
matrix: 使用point来仿真单个连续工作量，或者使用col来仿真不断增加的大
的连续的工作量。
num_large: 最大的大的IOs

./orion -run advanced \
-testname mytest \
-matrix point \
-num_small 0 \
-num_large 4 \
-size_large 1024 \
-num_disks 4 \
-type seq \
-num_streamIO 8 \
-simulate raid0 \
-cache_size 0 \
-write 0
-verbose

Commandline:
-run advanced -testname mytest -matrix point -num_small 0 -num_large 4 -size_lar
ge 1024 -num_disks 4 -type seq -num_streamIO 8 -simulate raid0 -cache_size 0 -wr
ite 0

This maps to this test:
Test: mytest
Small IO size: 8 KB
Large IO size: 1024 KB
IO Types: Small Random IOs, Large Sequential Streams
Number of Concurrent IOs Per Stream: 8
Force streams to separate disks: No
Simulated Array Type: RAID 0
Stripe Depth: 1024 KB
Write: 0%
Cache Size: 0 MB
Duration for each Data Point: 60 seconds
Small Columns:, 0
Large Columns:, 4
Total Data Points: 1

Name: /dev/sda5 Size: 102404703744
Name: /dev/sdb1 Size: 102404703744
Name: /dev/sdc1 Size: 102404703744
Name: /dev/sdd1 Size: 102404703744
4 FILEs found.

Maximum Large MBPS=66.88 @ Small=0 and Large=4

从测试数据看，在这种情况下，吞吐量是66.88M。理想的情况下：oracle可以达到95%。
下面的语句4个并发的会话。

select /*+ NO_MERGE(sales) */ count(*) from
(select /*+ FULL(s) PARALLEL (s,8) */* from all_sales s) sales

在一个很好平衡的数据仓库配置，应该有足够的IO来利用CPU。作为一个起始点，可以
使用下列规则：一个GHZ的CPU可以驱动100M。比如说有4个3G的CPUs，那么你的存储应
该提供4*3*100=1200MBPS的吞吐量。在RAC环境中，这个数量可以乘以节点的数目。

1. 1 disk
./orion_linux_x86-64 -run simple -num_disks 1 -testname mytest1

ORION VERSION 11.1.0.7.0

Commandline:
-run simple -num_disks 1 -testname mytest1

This maps to this test:
Test: mytest1
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:, 0
Large Columns:, 0, 1, 2
Total Data Points: 8

Name: /dev/sda5 Size: 102404703744
1 FILEs found.

Maximum Large MBPS=29.20 @ Small=0 and Large=2
Maximum Small IOPS=177 @ Small=4 and Large=0
Minimum Small Latency=7.59 @ Small=1 and Large=0

从这里看到这个磁盘的极限是177IOPS，29.20MBPS。

avg-cpu: %user %nice %sys %iowait %idle
0.10 0.00 0.13 12.38 87.39

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz
sda5 0.00 0.00 164.73 0.60 2635.67 9.62 1317.84 4.81 16.00

avgqu-sz await svctm %util
3.01 18.26 6.06 100.22

从IOSTAT的输出看到当这个磁盘的IOPS是164的时候，%util利用率已经是100%。等待时间是
18ms。

2. 2 disk
./orion_linux_x86-64 -run simple -num_disks 2 -testname mytest2

Commandline:
-run simple -num_disks 2 -testname mytest2

This maps to this test:
Test: mytest2
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:, 0
Large Columns:, 0, 1, 2, 3, 4
Total Data Points: 15

Name: /dev/sda5 Size: 102404703744
Name: /dev/sdb1 Size: 102404703744
2 FILEs found.

Maximum Large MBPS=50.94 @ Small=0 and Large=4
Maximum Small IOPS=330 @ Small=10 and Large=0
Minimum Small Latency=7.41 @ Small=1 and Large=0

从summary文件中看到两个磁盘的极限，MBPS是50.94M, IPOS是330。

avg-cpu: %user %nice %sys %iowait %idle
0.15 0.00 0.13 12.51 87.22

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda5 0.00 0.00 101.61 0.60 1622.49 14.46 811.24 7.23 16.02 1.03 10.11 7.56 77.29
sdb1 0.00 0.00 99.20 0.40 1600.00 12.85 800.00 6.43 16.19 0.99 9.91 7.50 74.70

从IOSTAT的输出看到当这个磁盘的IOPS是200的时候，%util利用率已经是77%。等待时间是
10ms。

avg-cpu: %user %nice %sys %iowait %idle
0.18 0.00 0.20 12.44 87.19

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda5 0.00 0.00 166.73 0.80 2686.97 16.03 1343.49 8.02 16.13 5.23 31.10 5.93 99.42
sdb1 0.00 0.00 165.73 0.40 2658.12 12.83 1329.06 6.41 16.08 4.87 29.54 5.81 96.47

从IOSTAT的输出看到当这个磁盘的IOPS是330左右的时候，%util利用率已经是99%。等待时间是
30ms。

avg-cpu: %user %nice %sys %iowait %idle
0.10 0.00 0.20 12.63 87.07

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda5 0.00 0.00 52.10 0.60 52533.87 9.62 26266.93 4.81 996.93 3.99 76.08 17.75 93.57
sdb1 0.00 0.00 49.70 0.20 51309.02 6.41 25654.51 3.21 1028.37 3.35 66.33 17.02 84.91

从IOSTAT的输出看到当这个磁盘的MBPS是51M左右的时候，%util利用率已经是93%。等待时间是
70ms。两个磁盘的条带大小是1M。第一块磁盘：26266.93/52.1 = 504K, 第二块磁盘：
25654.51/49.7=516K

3. 3 disk
./orion_linux_x86-64 -run simple -num_disks 3 -testname mytest3

Commandline:
-run simple -num_disks 3 -testname mytest3

This maps to this test:
Test: mytest3
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:, 0
Large Columns:, 0, 1, 2, 3, 4, 5, 6
Total Data Points: 22

Name: /dev/sda5 Size: 102404703744
Name: /dev/sdb1 Size: 102404703744
Name: /dev/sdc1 Size: 102404703744
3 FILEs found.

Maximum Large MBPS=73.25 @ Small=0 and Large=6
Maximum Small IOPS=492 @ Small=15 and Large=0
Minimum Small Latency=7.30 @ Small=1 and Large=0

从summary文件中看到三个磁盘的极限，MBPS是73.25M, IPOS是492。

avg-cpu: %user %nice %sys %iowait %idle
0.13 0.00 0.20 12.41 87.27

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda5 0.00 0.00 108.40 0.80 1731.20 16.00 865.60 8.00 16.00 1.34 12.32 7.24 79.02
sdb1 0.00 0.00 104.60 0.40 1676.80 12.80 838.40 6.40 16.09 1.16 11.03 6.99 73.36
sdc1 0.00 0.00 100.00 0.40 1609.60 12.80 804.80 6.40 16.16 1.14 11.23 7.16 71.88

从IOSTAT的输出看到当三个磁盘的IOPS是300的时候，%util利用率已经是70%。等待时间是
10ms。

avg-cpu: %user %nice %sys %iowait %idle
0.15 0.00 0.23 12.26 87.37

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda5 0.00 0.00 165.13 0.60 2658.12 9.62 1329.06 4.81 16.10 4.84 29.14 5.87 97.25
sdb1 0.00 0.00 160.72 0.20 2581.16 6.41 1290.58 3.21 16.08 4.22 26.16 6.01 96.65
sdc1 0.00 0.00 160.92 0.20 2571.54 6.41 1285.77 3.21 16.00 4.00 25.01 5.95 95.79

从IOSTAT的输出看到当三个磁盘的IOPS是485的时候，%util利用率已经是97%。等待时间是
29ms。

3. 3 disk
./orion_linux_x86-64 -run simple -num_disks 4 -testname mytest4

ORION VERSION 11.1.0.7.0

Commandline:
-run simple -num_disks 4 -testname mytest4

This maps to this test:
Test: mytest4
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:, 0
Large Columns:, 0, 1, 2, 3, 4, 5, 6, 7, 8
Total Data Points: 29

Name: /dev/sda5 Size: 102404703744
Name: /dev/sdb1 Size: 102404703744
Name: /dev/sdc1 Size: 102404703744
Name: /dev/sdd1 Size: 102404703744
4 FILEs found.

Maximum Large MBPS=63.24 @ Small=0 and Large=8
Maximum Small IOPS=649 @ Small=20 and Large=0
Minimum Small Latency=7.27 @ Small=1 and Large=0

从summary文件中看到四个磁盘的极限，MBPS是63.24M, IPOS是649。

avg-cpu: %user %nice %sys %iowait %idle
0.35 0.00 0.20 12.31 87.14

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda5 0.00 0.00 92.77 0.60 1487.55 14.46 743.78 7.23 16.09 1.05 11.28 7.22 67.43
sdb1 0.00 0.00 93.57 0.40 1500.40 12.85 750.20 6.43 16.10 1.14 12.11 7.42 69.72
sdc1 0.00 0.00 86.14 0.40 1375.10 12.85 687.55 6.43 16.04 0.96 11.08 7.29 63.13
sdd1 0.00 0.00 86.95 0.00 1394.38 0.00 697.19 0.00 16.04 0.88 10.09 7.21 62.67

从IOSTAT的输出看到当三个磁盘的IOPS是357的时候，%util利用率已经是70%。等待时间是
10ms。

avg-cpu: %user %nice %sys %iowait %idle
0.15 0.00 0.33 12.18 87.34

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda5 0.00 0.00 155.51 0.80 2459.32 9.62 1229.66 4.81 15.79 5.40 34.95 6.15 96.11
sdb1 0.20 0.00 163.33 0.40 2619.64 6.41 1309.82 3.21 16.04 5.35 32.73 5.84 95.67
sdc1 0.00 0.00 163.33 0.40 2606.81 6.41 1303.41 3.21 15.96 4.27 26.08 5.88 96.31
sdd1 0.00 0.00 157.92 0.00 2561.92 0.00 1280.96 0.00 16.22 5.09 31.12 5.99 94.67

从IOSTAT的输出看到当三个磁盘的IOPS是638的时候，%util利用率已经是96%。等待时间是
30ms。

响应时间+IOPS 就说明了系统的当前io状况啊,响应时间在 10ms 左右能达到的最大iops 能力，
是系统io能力的一个最重要指标。

衡量系统io能力，我们也是关注的高峰期一段时间内稳定运行的状况

简单来说，如果一个database在peak time显示出来的db file sequential/scattered read
average wait time的指标明显低于7 ms, 那么，我们不应该把焦点集中在Storage 上。虽然这个
指标不一定说明Storage 性能很好，但是至少表明系统的瓶颈并不在Storage 上1，改善Storage
性能未必能获得很高回报。反之，如果一个database在peak time显示出来的db file sequential/
scattered read average wait time的指标明显高于10 ms,我们可能需要关注Storage的性能是否
存在瓶颈，当然，同时也可以从降低Total IO的角度去处理。

一个random IO的理论时间是：
7ms = 4-5ms(磁盘平均寻道时间）+ 2ms (传输时间) + 一些其它的消耗
如果不考虑file system cache hit(raw device/direct IO) 以及storage cache hit , 同时没
有磁盘竞争，那么，db file sequntial read的时间就会是 7ms左右.

而由于file system cache hit和storage cache hit的情况下，没有磁盘竞争的系统db file
sequntial read 会小于 7ms 如果有磁盘竞争，而且竞争产生的延迟> file system cache hit和
storage cache hit的好处，就会大于7ms .10ms 可以说是一个经验值，就是磁盘竞争产生的延迟
比较高了