热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

【转】Orionoracle提供的测试io性能的工具

Orion是oracle提供的测试io性能的工具。它可以用来模拟Oracle数据库IO,也可以用来仿真ASM的条带化的功能。Orion可以支持下列IO负载1.小的随机

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: 输入文件必须是.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

常见问题:

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

如果使用的是NAS
 确保文件系统被加载
 .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 可以说是一个经验值,就是磁盘竞争产生的延迟
比较高了


文章摘自:http://space.itpub.net/25105315/viewspace-694261


推荐阅读
  • 上图是InnoDB存储引擎的结构。1、缓冲池InnoDB存储引擎是基于磁盘存储的,并将其中的记录按照页的方式进行管理。因此可以看作是基于磁盘的数据库系统。在数据库系统中,由于CPU速度 ... [详细]
  • YOLOv7基于自己的数据集从零构建模型完整训练、推理计算超详细教程
    本文介绍了关于人工智能、神经网络和深度学习的知识点,并提供了YOLOv7基于自己的数据集从零构建模型完整训练、推理计算的详细教程。文章还提到了郑州最低生活保障的话题。对于从事目标检测任务的人来说,YOLO是一个熟悉的模型。文章还提到了yolov4和yolov6的相关内容,以及选择模型的优化思路。 ... [详细]
  • 本文介绍了PhysioNet网站提供的生理信号处理工具箱WFDB Toolbox for Matlab的安装和使用方法。通过下载并添加到Matlab路径中或直接在Matlab中输入相关内容,即可完成安装。该工具箱提供了一系列函数,可以方便地处理生理信号数据。详细的安装和使用方法可以参考本文内容。 ... [详细]
  • 图解redis的持久化存储机制RDB和AOF的原理和优缺点
    本文通过图解的方式介绍了redis的持久化存储机制RDB和AOF的原理和优缺点。RDB是将redis内存中的数据保存为快照文件,恢复速度较快但不支持拉链式快照。AOF是将操作日志保存到磁盘,实时存储数据但恢复速度较慢。文章详细分析了两种机制的优缺点,帮助读者更好地理解redis的持久化存储策略。 ... [详细]
  • 本文介绍了在Windows环境下如何配置php+apache环境,包括下载php7和apache2.4、安装vc2015运行时环境、启动php7和apache2.4等步骤。希望对需要搭建php7环境的读者有一定的参考价值。摘要长度为169字。 ... [详细]
  • 单页面应用 VS 多页面应用的区别和适用场景
    本文主要介绍了单页面应用(SPA)和多页面应用(MPA)的区别和适用场景。单页面应用只有一个主页面,所有内容都包含在主页面中,页面切换快但需要做相关的调优;多页面应用有多个独立的页面,每个页面都要加载相关资源,页面切换慢但适用于对SEO要求较高的应用。文章还提到了两者在资源加载、过渡动画、路由模式和数据传递方面的差异。 ... [详细]
  • Activiti7流程定义开发笔记
    本文介绍了Activiti7流程定义的开发笔记,包括流程定义的概念、使用activiti-explorer和activiti-eclipse-designer进行建模的方式,以及生成流程图的方法。还介绍了流程定义部署的概念和步骤,包括将bpmn和png文件添加部署到activiti数据库中的方法,以及使用ZIP包进行部署的方式。同时还提到了activiti.cfg.xml文件的作用。 ... [详细]
  • 本文分析了Wince程序内存和存储内存的分布及作用。Wince内存包括系统内存、对象存储和程序内存,其中系统内存占用了一部分SDRAM,而剩下的30M为程序内存和存储内存。对象存储是嵌入式wince操作系统中的一个新概念,常用于消费电子设备中。此外,文章还介绍了主电源和后备电池在操作系统中的作用。 ... [详细]
  • 本文介绍了关系型数据库和NoSQL数据库的概念和特点,列举了主流的关系型数据库和NoSQL数据库,同时描述了它们在新闻、电商抢购信息和微博热点信息等场景中的应用。此外,还提供了MySQL配置文件的相关内容。 ... [详细]
  • Hibernate延迟加载深入分析-集合属性的延迟加载策略
    本文深入分析了Hibernate延迟加载的机制,特别是集合属性的延迟加载策略。通过延迟加载,可以降低系统的内存开销,提高Hibernate的运行性能。对于集合属性,推荐使用延迟加载策略,即在系统需要使用集合属性时才从数据库装载关联的数据,避免一次加载所有集合属性导致性能下降。 ... [详细]
  • OpenCV4.5.0+contrib编译流程及解决错误方法
    本文介绍了OpenCV4.5.0+contrib的编译流程,并提供了解决常见错误的方法,包括下载失败和路径修改等。同时提供了相关参考链接。 ... [详细]
  • 本文介绍了解决mysql 5.1启动问题的方法,通过修改my.ini文件中的相关配置,包括innodb_data_home_dir和skip-innodb等,可以解决启动问题。同时还介绍了如何调整内存池来存储metadata信息。 ... [详细]
  • OpenMap教程4 – 图层概述
    本文介绍了OpenMap教程4中关于地图图层的内容,包括将ShapeLayer添加到MapBean中的方法,OpenMap支持的图层类型以及使用BufferedLayer创建图像的MapBean。此外,还介绍了Layer背景标志的作用和OMGraphicHandlerLayer的基础层类。 ... [详细]
  • 颜色迁移(reinhard VS welsh)
    不要谈什么天分,运气,你需要的是一个截稿日,以及一个不交稿就能打爆你狗头的人,然后你就会被自己的才华吓到。------ ... [详细]
  • 近期,某用户在重启RAC一个节点的数据库实例时,发现启动速度非常慢。同时业务部门反馈连接RAC存活节点的业务也受影响。通过对日志的分析, ... [详细]
author-avatar
訫梦沁_245
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有