一直弄不清楚的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 Report |
| ||||||||
| 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 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 Report | |||||||||
| 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 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 Report | |||||||||
| 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 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请求大小,文件系统块大小,页缓存机制,硬盘的寻道,旋转,读取数据的速率,分布式文件系统会受到更多因素的影响,应视具体情况具体分析。