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 可以說是一個經驗值,就是磁盤競爭產生的延遲
比較高了


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章