3

如果不耐烦,请跳到下面的“问题”标题。

语境

我从事 Unix(like) 系统管理和基础设施开发工作,但我认为我的问题由程序员回答得最好:o)

我想做的是学习如何使用 iozone 对文件系统(普通、卷管理、虚拟化、加密等)进行基准测试。作为练习,我在我的 slug ( http://www.nslu2-linux.org/ )中对用作系统磁盘的 USB pendrive 进行了基准测试,格式分别为 vfat、ntfs、ext3、ext4 和 xfs。该测试产生了一些令人惊讶的结果,这些结果发布在下面。然而,结果让我感到惊讶的原因很可能是因为我对 iozone 还很陌生,并不真正知道如何解释这些数字。因此,这篇文章。

在我的测试中,iozone 对 11 种不同的文件操作进行了基准测试,但仅针对一种记录大小(4k,与所有测试文件系统的块大小匹配)和一种文件大小 (512MB)。文件系统记录大小和文件大小的片面性当然会给测试带来一些偏差。无论如何,文件操作在下面列出,每个都有我自己的简短解释:

  • 初始写入:按顺序将新数据写入磁盘,常规文件使用
  • 重写:将新数据附加到现有的顺序、常规文件使用中
  • read:顺序读取数据,常规文件使用
  • 重新读取:顺序重新读取数据(缓冲测试,还是什么?)
  • 反向阅读:???
  • 大步阅读:???
  • 随机读取:非顺序读取,通常是数据库使用
  • 随机写入:非顺序写入,通常使用数据库
  • pread:读取某个位置的数据 - 用于索引数据库?
  • pwrite:在某个位置写入数据 - 用于索引数据库?
  • 混合工作量:(很明显)

其中一些操作看起来很简单。我猜初始写入、重写和读取都用于常规文件处理,包括让指针寻找直到到达某个块,顺序读取或写入(通常通过许多块),有时由于碎片而不得不向前跳跃一点文件。重读测试的唯一目标(我猜)是缓冲测试。同时,随机读/写是典型的数据库操作,其中指针必须在收集数据库记录的同一文件中从一个地方跳到另一个地方,例如在连接表时。

那么问题是什么?

到目前为止,一切都很好。我非常感谢对上述假设的任何更正,尽管它们似乎相当普遍。现在是真正的问题:你为什么要做反向阅读?什么是跨步阅读?有人告诉我,“位置”操作 pread 和 pwrite 用于索引数据库,但为什么不简单地将索引保存在内存中呢?或者这是实际发生的情况,然后一旦给定某个索引,pread 就可以方便地跳转到记录的确切位置?您还使用 pread/pwrite 做什么?

总而言之,到目前为止,我觉得我只能半途而废地解释我的 iozone 结果。我或多或少知道为什么随机操作中的高数字会为数据库提供良好的文件系统,但为什么我需要以相反的顺序读取文件,以及良好的跨步读取告诉我什么?这些操作的典型应用用途是什么?

奖金问题

既然问了,这里有一个额外的问题。作为给定文件系统的管理员,感激地从有洞察力的程序员那里学会了如何解释我的文件系统基准;) - 有人对如何对文件系统的实际使用进行分析有什么建议吗?试验文件系统记录(块)大小是微不足道的,虽然很耗时。关于给定文件系统中文件的大小和分布,“查找”是我的朋友。但是我该怎么做才能计算实际的文件系统调用,如 read()、pwrite() 等?

我也非常感谢任何关于其他资源对文件系统测试结果的影响的评论,例如处理器能力和 RAM 容量和速度的作用。例如,当我想在带有 266 MHz ARM Intel XScale 处理器和 32/8 MB SD/闪存?

具有建筑思维的文档?

因为我不喜欢重复自己太多,我也不喜欢问别人,所以,如果这些问题不能以简短的方式回答,我将非常感谢进一步文档的链接,重要的是不是它解释了上述文件操作的实际作用(我可以参考 API),但是该文档具有架构意识,也就是说,它解释了这些操作通常如何在现实生活中的应用程序中使用。

试验结果

正确的。我承诺了我相当不起眼的 USB pendrive 文件系统测试的结果。我的主要期望是写入结果通常很差(作为闪存驱动器,考虑到它的性质,通常具有比管理它的实际文件系统更大的块大小,这意味着要写入一个较小的更改相对大量的未更改数据必须重写),并且读取结果很好。事实证明,要点是:

  • vfat 在所有操作上都做得很好,除了有点晦涩(对我来说,无论如何)反向和跨步读取。我猜缺少功能消除了很多簿记。

  • ntfs 在重写(追加)和读取操作方面很糟糕,使其成为常规文件操作的糟糕候选者。它还很糟糕的预操作,使其成为索引数据库的糟糕候选者。

  • 令人惊讶的是,ext3 和 ext4,后者在所有操作上都略胜一筹,在初始写入、重写、读取、随机写入和 pwrite 操作方面表现不佳,这使得它们不适合常规文件使用以及频繁更新的数据库。但是,ext4 是随机读取和预读的大师,使其成为某种静态数据库的绝佳候选者(?)。ext3 和 ext4 在晦涩难懂的反向读取和跨步读取操作上得分都很高,不管这意味着什么。

  • 无与伦比的全面测试获胜者是 xfs,其唯一的弱点似乎是反向阅读。在初始写入、重写、读取、随机写入和 pwrite 方面,它是最好的,使其成为常规文件使用以及(强烈更新)数据库的绝佳候选者。在重读、随机阅读和预读方面,它是亚军,使其成为(有些静态的)数据库的良好候选者。它在跨步阅读方面也做得很好——不管这意味着什么!

欢迎对这些结果的解释发表任何评论!下面列出了数字(由于长度原因有所删减),一个 iozone 测试套件 pr。文件系统类型,均在标准 4GB Verbatim pendrive(橙色 ;))上进行测试,停靠在配备 N450 1.66Ghz Atom CPU 和 2GB DDR2 667 Mhz RAM 的三星 N105P 笔记本电脑上,运行 Linux 3.2.0-24 x86 内核使用加密交换(是的,我知道,我应该安装一个 64 位 Linux 并让交换保持清晰!)。

问候,托斯滕

PS。写完这篇文章后,我发现 Debian NSLU2 发行版显然不支持 xfs。不过,我的问题仍然存在!

--- vfat ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Mon Jun  4 14:23:57 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /mnt/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000002 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =   12864.82 KB/sec
Parent sees throughput for  1 initial writers   =    3033.39 KB/sec

Children see throughput for  1 rewriters    =   25271.86 KB/sec
Parent sees throughput for  1 rewriters     =    2876.36 KB/sec

Children see throughput for  1 readers      =  685333.00 KB/sec
Parent sees throughput for  1 readers       =  682464.06 KB/sec

Children see throughput for 1 re-readers    =  727929.94 KB/sec
Parent sees throughput for 1 re-readers     =  726612.47 KB/sec

Children see throughput for 1 reverse readers   =  458174.00 KB/sec
Parent sees throughput for 1 reverse readers    =  456910.21 KB/sec

Children see throughput for 1 stride readers    =  351768.00 KB/sec
Parent sees throughput for 1 stride readers     =  351504.09 KB/sec

Children see throughput for 1 random readers    =  553705.94 KB/sec
Parent sees throughput for 1 random readers     =  552630.83 KB/sec

Children see throughput for 1 mixed workload    =  549812.50 KB/sec
Parent sees throughput for 1 mixed workload     =  547645.03 KB/sec

Children see throughput for 1 random writers    =   19958.66 KB/sec
Parent sees throughput for 1 random writers     =    2752.23 KB/sec

Children see throughput for 1 pwrite writers    =   13355.57 KB/sec
Parent sees throughput for 1 pwrite writers     =    3119.04 KB/sec

Children see throughput for 1 pread readers     =  574273.31 KB/sec
Parent sees throughput for 1 pread readers  =  572121.97 KB/sec

--- ntfs ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Mon Jun  4 13:59:37 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /mnt/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000002 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =   11153.75 KB/sec
Parent sees throughput for  1 initial writers   =    2848.69 KB/sec

Children see throughput for  1 rewriters    =    8723.95 KB/sec
Parent sees throughput for  1 rewriters     =    2794.81 KB/sec

Children see throughput for  1 readers      =   24935.60 KB/sec
Parent sees throughput for  1 readers       =   24878.74 KB/sec

Children see throughput for 1 re-readers    =  144415.05 KB/sec
Parent sees throughput for 1 re-readers     =  144340.90 KB/sec

Children see throughput for 1 reverse readers   =   76627.60 KB/sec
Parent sees throughput for 1 reverse readers    =   76362.93 KB/sec

Children see throughput for 1 stride readers    =  367293.25 KB/sec
Parent sees throughput for 1 stride readers     =  366002.25 KB/sec

Children see throughput for 1 random readers    =  505843.41 KB/sec
Parent sees throughput for 1 random readers     =  500556.16 KB/sec

Children see throughput for 1 mixed workload    =  553075.56 KB/sec
Parent sees throughput for 1 mixed workload     =  551754.97 KB/sec

Children see throughput for 1 random writers    =    9747.23 KB/sec
Parent sees throughput for 1 random writers     =    2381.89 KB/sec

Children see throughput for 1 pwrite writers    =   10906.05 KB/sec
Parent sees throughput for 1 pwrite writers     =    1931.43 KB/sec

Children see throughput for 1 pread readers     =   16730.47 KB/sec
Parent sees throughput for 1 pread readers  =   16194.80 KB/sec

--- 分机 3 ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Sun Jun  3 16:05:27 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /media/verbatim/1/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =    3704.61 KB/sec
Parent sees throughput for  1 initial writers   =    3238.73 KB/sec

Children see throughput for  1 rewriters    =    3693.52 KB/sec
Parent sees throughput for  1 rewriters     =    3291.40 KB/sec

Children see throughput for  1 readers      =  103318.38 KB/sec
Parent sees throughput for  1 readers       =  103210.16 KB/sec

Children see throughput for 1 re-readers    =  908090.88 KB/sec
Parent sees throughput for 1 re-readers     =  906356.05 KB/sec

Children see throughput for 1 reverse readers   =  744801.38 KB/sec
Parent sees throughput for 1 reverse readers    =  743703.54 KB/sec

Children see throughput for 1 stride readers    =  623353.88 KB/sec
Parent sees throughput for 1 stride readers     =  622295.11 KB/sec

Children see throughput for 1 random readers    =  725649.06 KB/sec
Parent sees throughput for 1 random readers     =  723891.82 KB/sec

Children see throughput for 1 mixed workload    =  734631.44 KB/sec
Parent sees throughput for 1 mixed workload     =  733283.36 KB/sec

Children see throughput for 1 random writers    =     177.59 KB/sec
Parent sees throughput for 1 random writers     =     137.83 KB/sec

Children see throughput for 1 pwrite writers    =    2319.47 KB/sec
Parent sees throughput for 1 pwrite writers     =    2200.95 KB/sec

Children see throughput for 1 pread readers     =   13614.82 KB/sec
Parent sees throughput for 1 pread readers  =   13614.45 KB/sec

--- 分机 ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Sun Jun  3 17:59:26 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /media/verbatim/2/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000005 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =    4086.64 KB/sec
Parent sees throughput for  1 initial writers   =    3533.34 KB/sec

Children see throughput for  1 rewriters    =    4039.37 KB/sec
Parent sees throughput for  1 rewriters     =    3409.48 KB/sec

Children see throughput for  1 readers      = 1073806.38 KB/sec
Parent sees throughput for  1 readers       = 1062541.84 KB/sec

Children see throughput for 1 re-readers    =  991162.00 KB/sec
Parent sees throughput for 1 re-readers     =  988426.34 KB/sec

Children see throughput for 1 reverse readers   =  811973.62 KB/sec
Parent sees throughput for 1 reverse readers    =  810333.28 KB/sec

Children see throughput for 1 stride readers    =  779127.19 KB/sec
Parent sees throughput for 1 stride readers     =  777359.89 KB/sec

Children see throughput for 1 random readers    =  796860.56 KB/sec
Parent sees throughput for 1 random readers     =  795138.41 KB/sec

Children see throughput for 1 mixed workload    =  741489.56 KB/sec
Parent sees throughput for 1 mixed workload     =  739544.09 KB/sec

Children see throughput for 1 random writers    =     499.05 KB/sec
Parent sees throughput for 1 random writers     =     399.82 KB/sec

Children see throughput for 1 pwrite writers    =    4092.66 KB/sec
Parent sees throughput for 1 pwrite writers     =    3451.62 KB/sec

Children see throughput for 1 pread readers     =  840101.38 KB/sec
Parent sees throughput for 1 pread readers  =  831083.31 KB/sec

--- xfs ---

Iozone: Performance Test of File I/O
        Version $Revision: 3.397 $
    Compiled for 32 bit mode.
    Build: linux 

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
             Ben England.

Run began: Mon Jun  4 14:47:49 2012

Record Size 4 KB
File size set to 524288 KB
Command line used: iozone -l 1 -u 1 -r 4k -s 512m -F /mnt/iozone.tmp
Output is in Kbytes/sec
Time Resolution = 0.000005 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 1 
Max process = 1 
Throughput test with 1 process
Each process writes a 524288 Kbyte file in 4 Kbyte records

Children see throughput for  1 initial writers  =   21854.47 KB/sec
Parent sees throughput for  1 initial writers   =    3836.32 KB/sec

Children see throughput for  1 rewriters    =   29420.40 KB/sec
Parent sees throughput for  1 rewriters     =    3955.65 KB/sec

Children see throughput for  1 readers      =  624136.75 KB/sec
Parent sees throughput for  1 readers       =  614326.13 KB/sec

Children see throughput for 1 re-readers    =  577542.62 KB/sec
Parent sees throughput for 1 re-readers     =  576533.42 KB/sec

Children see throughput for 1 reverse readers   =  483368.06 KB/sec
Parent sees throughput for 1 reverse readers    =  482598.67 KB/sec

Children see throughput for 1 stride readers    =  537227.12 KB/sec
Parent sees throughput for 1 stride readers     =  536313.77 KB/sec

Children see throughput for 1 random readers    =  525219.19 KB/sec
Parent sees throughput for 1 random readers     =  524062.07 KB/sec

Children see throughput for 1 mixed workload    =  561513.50 KB/sec
Parent sees throughput for 1 mixed workload     =  560142.18 KB/sec

Children see throughput for 1 random writers    =   24118.34 KB/sec
Parent sees throughput for 1 random writers     =    3117.71 KB/sec

Children see throughput for 1 pwrite writers    =   32512.07 KB/sec
Parent sees throughput for 1 pwrite writers     =    3825.54 KB/sec

Children see throughput for 1 pread readers     =  525244.94 KB/sec
Parent sees throughput for 1 pread readers  =  523331.93 KB/sec
4

3 回答 3

3

我唯一需要深入挖掘文件系统性能的时候是在 Windows 系统上。无论您使用什么操作系统/文件系统,一般原则都适用...

为什么你会做反向阅读?

当程序运行时,它读取块 987654,然后使用该数据确定它需要块 123456。这可能发生在连接上:您的 Db 可能正在使用 table1 上的索引从表 2 中选择记录(使用索引)。拣货操作可能以表 1 的顺序进行(与表 2 的顺序相反)。

当使用两个键时,可能会发生类似的情况。

什么是跨步阅读?

读取每个第 N 个块 ex。读取块 12345600 然后读取块 12345700 然后块 12345800 的步幅为 100。想象一个包含许多和/或大列的表。该表可能包含需要多个文件系统块来保存数据的行。通常,数据库会将这些数据组织到每一行的记录中,每条记录占用几个连续的文件系统块。如果您的数据库行占用 10 个文件系统块并且您在两列上进行选择,您可能只需要读取该 10 个块记录的第 1 个和第 6 个块。然后,您的查询需要读取块 10001、10006、10011、10016、10021、10026 - 步长为 5。

有人告诉我,“位置”操作 pread 和 pwrite 用于索引数据库,但为什么不简单地将索引保存在内存中呢?

索引的大小可能会超过合理的 RAM 使用量。或者,您之前的使用将其他索引或数据调用到 ram 中,导致未使用的索引从文件系统/数据库缓存中删除。

或者这是实际发生的情况,然后一旦给定某个索引,pread 就可以方便地跳转到记录的确切位置? 是的,这可能就是您的数据库正在做的事情。

您还使用 pread/pwrite 做什么?

一些数据文件具有预定义的“有趣”位置。这可能是 B-Tree 索引、表头、日志/日志尾部或其他内容的根,具体取决于您的 Db 实现。pread/rwrite 正在测试重复跳到一组特定位置的性能,而不是测试均匀随机混合的位置。

链接?

存在适用于所有主流操作系统的系统实用程序,可以捕获每个操作系统文件系统操作。我认为这些在 *NIX 系统上可能被命名为 DTRACE 或 pTAP 或 pTRACE。您可以使用来自这些监视器的海量数据(智能过滤)来查看系统中的磁盘访问模式。

然后一般的经验法则是,对于 Db 的使用来说,大量的 RAM 是有帮助的。然后你的所有索引一直驻留在 RAM 中。

于 2012-06-05T14:54:16.153 回答
1

抱歉:我无法添加有关您询问的特定系统调用的信息。所以我添加了一些自以为是的内容,而不是......

在我看来,iozone 并不是一个非常有趣的基准测试工具。我认为,分析各种系统调用也不是那么有趣。

重要的是文件系统在现实世界中的工作方式。然而,用真实世界场景进行基准测试可能非常耗时;例如,创建有效的测试环境可能需要很长时间。这就是为什么基准工具确实派上用场的原因。但是基准测试工具应该能够以尽可能接近实际应用的方式工作;此外,如果基准测试工具以粗暴的方式工作通常很好,以便探索所涉及的硬件/软件的限制。

满足这些要求的两个基准测试工具是fio和 Oracle 的orion。使用这两种工具,可以相对容易地指定一个将使用读取和写入的合理组合的基准,并指定基准应该运行的并行度。并且可以执行设备级和 FS 级基准测试;这很好,因为有时您希望在没有特定文件系统开销的情况下对存储设备进行基准测试。与 Orion 相比,fio 具有动态邮件列表的优势,其中非常有可能获得好的答案(我还没有找到 Orion 的邮件列表)。

于 2012-06-05T18:39:24.370 回答
1

我可以就您问题的两个部分提供一些背景信息。由于观察了一些机械工程应用程序的 I/O 行为,引入了“向后读取”测试。这些应用程序经常会从磁盘顺序向前然后向后读取。有人猜测这与(线性代数)前向和后向替换有关,或者与依赖磁带驱动器的原始实现有关。

至于跨步访问,这是许多地震勘探应用程序(深度和/或时间偏移 IIRC)的常见 I/O 模式。与“向后读取”场景一样,这也是在观察这些应用程序的 I/O 行为后引入的。

于 2015-11-02T19:42:02.563 回答