一直弄不清楚的
iozone
請求大小終於清楚了，原來
iozone
中的記錄大小是由其應用層劃分的，最簡單的情形是多個
for迴圈
read
。檔案系統的讀寫速率與讀寫的檔案大小是沒有多大關係的，在寫的時候可能大檔案的在寫元資料及資料組織方面比小檔案的開銷要大，所以寫效率隨測試檔案大小的增加會有小幅度的下降。關鍵影響檔案系統效率的其實是上層的請求大小，大的檔案在應用層分為多個請求，請求的大小由應用程式決定，每次請求相當於一次中斷，需切換至核心，讀完該次請求所有的資料後該次請求才返回，從硬碟的角度看，每次讀取的資料越多，資料讀取在整個讀的過程中佔的比重越大
( 尋道時間【均值
4.6ms
】，旋轉時間【均值
3ms】，資料傳輸時間
)，硬碟利用率越高，使用預讀取可以一次讀取多個連續的資料塊。
雖然io
請求越大，磁碟利用率越高，但並不是
io請求越大越好，由於應用程式緩衝區及計算機記憶體大小的限制，請求過大會造成緩衝區的頻繁飽和，導致效率降低，所以通常每次
io請求過小，過大都不能是系統效率達到最高，而是中間某個值。
以iozone
測試ext3
檔案系統的資料為例
（測試命令：
./iozone -i 0 -i 1 -rab /root/test-iozone.xls -g 16m -n 1m
）測試物件為read，re-read，write，re-write（省略了部分資料）
速率單位為：kbytes/sec，硬碟的典型速率為80mbytes/sec此處測試檔案系統效率，由於採用了緩衝機制，計算方式為讀取資料/讀取資料時間，所以效率會高於硬碟效率。
writer report48
1632
64128
256512
1024
1024
282084
317116
328090
333983
332355
333025
318504
304763
287234
2048
286313
305530
318065
322568
326951
324518
318065
304706
297149
4096
280548
297307
308852
314742
317934
316680
310774
299109
292947
8192
272331
291300
300865
306138
309564
309129
306027
293242
287267
16384
270166
289546
295990
305250
306845
307617
302466
291332
286548
re-writer report48
1632
64128
256512
1024
1024
771670
851195
883409
930894
916786
899694
861093
756848
725280
2048
703758
770203
801837
815231
836589
819196
796558
727294
685888
4096
655975
707316
742181
775621
774153
780803
756995
686321
663525
8192
641652
691832
718480
749234
763756
754465
743849
678874
642865
16384
633740
687539
726246
746522
761191
766677
737849
680540
647485
reader report
1024
1499217
1774922
1914144
1969440
2068064
2147692
1799462
1309518
1155864
2048
1458688
1719429
1851755
1896314
1986660
2013672
1763917
1247122
1059987
4096
1468138
1742237
1912315
1943027
1980661
2046975
1808253
1221566
1012140
8192
1490027
1788563
1919881
1949952
2020708
2031701
1840489
1191399
972707
16384
1513951
1827169
1939211
1995640
2067136
2113807
1886715
1216428
973614
re-reader report48
1632
64128
256512
1024
1024
1651398
2004366
2073055
2173780
2311849
2275110
1885572
1345623
1154621
2048
1564706
1873565
1996356
2068465
2133188
2275596
1858566
1281543
1049625
4096
1572412
1874752
2009857
2084478
2104910
2168407
1845153
1241965
1013095
8192
1554752
1907729
1996637
2039782
2134436
2137224
1924289
1217402
988177
16384
1586219
1889517
2022243
2024984
2121180
2172961
1895615
1227992
978801
根據write
，re-write
的比較可以看出，寫最高速率點出現在請求為
32k，
64k的情況下，並且
re-write
的效能遠高於
write
的效能，主要是
re-write
比write
少了申請塊，組織檔案，寫元資料的開銷。
由於read
不用寫元資料，所以
read
和re-read
的效能差距不大，
re-read
可能使用快取資料，故效率比
read
要高，讀最高速率點出現在
64k,128k
的情況下。
檔案系統的效率有很多因素決定，包括io請求大小，檔案系統塊大小，頁快取機制，硬碟的尋道，旋轉，讀取資料的速率，分布式檔案系統會受到更多因素的影響，應視具體情況具體分析。
檔案系統效能測試
1 衡量指標 iops 隨機小i o讀寫能力 頻寬 順序大i o連續讀寫能力 2 效能關鍵點 順序 隨機讀寫 sequential random 目錄操作 檔案建立 刪除 查詢 更新 大量小檔案讀寫 lots of small files 大檔案讀寫 large file 3 其他指標 cpu佔用率...
Linux檔案系統效能優化
由於各種的i o負載情形各異，linux系統中檔案系統的預設配置一般來說都比較中庸，強調普遍適用性。然而在特定應用下，這種配置往往在i o效能方面不能達到最優。因此，如果應用對i o效能要求較高，除了採用效能更高的硬體 如磁碟 hba卡 cpu mem等 外，我們還可以通過對檔案系統進行效能調優，來...
系統效能分析
當系統變慢時候，我們首先關注的可能是cpu的指標，有時候發現cpu使用率一點都不高，但是系統還是卡，這時可能就需要關心另外乙個影響效能的東西 磁碟的io效能。通過top命令中的 wa可以獲取系統當前的io狀態，如果該值居高不小，那磁碟的io可能就有問題了。另外可以通過iotop命令來詳細了解什麼程式...