再好的算法、實現。最終還是要來進行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 父表的查詢無法應用於子表的索引導致的。。。