系統IO績效參數及不同方案關注點

 再好的演算法、實現。最終還是要來進行IO

使用的是傳統的機械硬碟，儲存大資料時還行，但是資料庫內容擷取就實在是差到一個境界了。特此進行一番探索：    

0 磁碟 效能：

在介紹磁碟 I/O 監控命令前，我們需要瞭解磁碟 I/O 效能監控的指標，以及每個指標的所揭示的磁碟某方面的效能。磁碟 I/O 效能監控的指標主要包括：

　　1) 每秒 I/O 數（  [r/s w/s]）- 每秒處理的請求數

　　IOPS:一次磁碟的連續讀或者連續寫稱為一次磁碟 I/O。

　　隨機讀寫頻繁的應用的關鍵衡量指標 比如主要提到的關聯式資料庫:)

　　固態硬碟的這個可以最佳化到恐怖的境界~可惜估計項目裡是沒有必要用了..　　

　　IOPS（每秒IO次數） = 1s/(尋道時間+旋轉延遲+資料轉送時間)

　　可以估算一下：1W轉的硬碟 IOPS ：IOPS = 1000 / (3 + 60000/10000/2 + 32K / 136K) = 167  

 

　　2) 輸送量（ [rkb/s wkb/s]）- 請求大小

　　Throughput: 硬碟傳輸資料流的速度，傳輸資料為讀出資料和寫入資料的和。

　　連續請求的關鍵衡量指標 比如線上視頻

　　 

　　3) 平均 I/O 資料尺寸 (avgrq-sz) - 每次請求的大小

　　輸送量除以 I/O 數目， avgrq-sz < 32K 隨機存取為主。 avgrq-sz > 32K  順序儲存為主

 

　　4) 磁碟啟用時間百分比（ %util） - 磁碟利用率

　　Utilization: 磁碟在資料轉送和處理命令（如尋道）處於活動狀態。

　　磁碟利用率與資源爭用程度成正比，與效能成反比。

 

　　5) 服務時間（ svctm） - 處理請求的能力

　　指磁碟讀或寫操作執行的時間，包括尋道，旋轉時延，和資料轉送等時間。其大小一般和磁碟效能有關， CPU/ 記憶體的負荷也會對其有影響，請求過多也會間接導致服務時間的增加。如果該值持續超過 20ms，一般可考慮會對上層應用產生影響。 這裡主要指的是指的是FC, SAS, SATA磁碟，轉速通常為5400/7200/1W轉。
　　尋道時間 Tseek是指將讀寫磁頭移動至正確的磁軌上所需要的時間。尋道時間越短，I/O操作越快，目前磁碟的平均尋道時間一般在3－15ms。
　　旋轉延遲 Trotation是指碟片旋轉將請求資料所在扇區移至讀寫磁頭下方所需要的時間。旋轉延遲取決於磁碟轉速，通常使用磁碟旋轉一周所需時間的1/2表示。比如，7200 rpm的磁碟平均旋轉延遲大約為60*1000/7200/2 = 4.17ms，而轉速為15000 rpm的磁碟其平均旋轉延遲約為2ms。
　　資料轉送時間 Ttransfer是指完成傳輸所請求的資料所需要的時間，它取決於資料轉送率，其值等於資料大小除以資料轉送率。目前IDE/ATA能達到133MB/s，SATA II可達到300MB/s的介面資料轉送率，資料轉送時間通常遠小於前兩部分消耗時間。簡單計算時可忽略。

 

　　6) I/O 等待隊列長度（ avgqu-sz） - 超過處理能力的請求數目

　　待處理的 I/O 請求，當請求持續超出磁碟處理能力，該值將增加。

　　avgqu-sz > 2 可以認為存在I/O效能問題。

 

　　7) 等待時間（ await）- 請求完成耗時

　　等待執行的時間， await 的大小一般取決於服務時間 (svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。

　　a) : svctm ~~ await    I/O 幾乎沒有等待時間

　　b) :  await >> svctm   I/O 隊列太長，應用得到的回應時間變慢

 ------------------------------------------------------------------------------

根據上述的內容，再來實戰看看

 建立大檔案： time dd if=./test1 of=./test bs=10M count=1000

100+0 records in
100+0 records out
1048576000 bytes (1.0 GB) copied, 8.39376 s, 125 MB/s

real    0m8.496s
user    0m0.000s
sys     0m1.341s

可以看到讀寫速度在125M左右， 處理1G的資料，要8.5S左右

同時，使用iostat 統計磁碟IO

 iostat -d -k -x 2

-d : 顯示存放裝置 　　-k 以KB大小展示　　-x 展示詳細內容 　　-p 列印指定裝置資訊

這裡面的參數基本上都是I/O效能的的一個方向。

比較特殊的是，rrqm、wrqm 這個欄位很少看到解釋，在這裡翻了出來http://cherry.world.edoors.com/Cdx6RbRHlOjQ

是反饋OS的對請求處理的一個參數，指每秒將多少個邏輯請求合并為一次物理請求。

 

昨天碰到一處問題，POSTGRES 持續佔用一個CPU已耗用時間，開始以為是效能在io上面，查看後，發現R/S 僅在0.7M/S左右。

可以排除IO，轉向查詢語句最佳化。

學習的初衷是解決IO過慢的問題，觀察後發現問題在於PSQL 父表的查詢無法應用於子表的索引導致的。。。