为什么文件系统密集型脚本在 ram 磁盘上不快

Question

我有一个创建大量文件和目录的脚本。该脚本对处理大量文件和目录的程序进行黑盒测试。测试次数增加，测试时间过长（超过 2 秒）。我以为我在 ram 磁盘中运行测试。

我在/dev/shm. 奇怪的是它并没有跑得更快。平均运行时间与普通硬盘大致相同。我还尝试了用 perl 编写的基于保险丝的 ram 磁盘。该网站不见了，但我在互联网档案中找到了它。熔断器 ram 磁盘上的平均运行时间甚至更慢。也许是因为 perl 代码的次优实现。

这是我的脚本的简化版本：

#! /bin/sh

preparedir() {
  mkdir foo
  mkdir bar
  touch bar/file
  mkdir bar/baz
  echo qux > bar/baz/file
}

systemundertest() {
  # here is the black box program that i am testing
  # i do not know what it does exactly
  # but it must be reading the files
  # since it behaves differently based on them
  find $1 -type f -execdir cat '{}' \; > /dev/null

singletest() {
  mkdir actual
  (cd actual; preparedir)
  systemundertest actual
  mkdir expected
  (cd expected; preparedir)
  diff -qr actual expected
}

manytests() {
  while read dirname; do
    rm -rf $dirname
    mkdir $dirname
    (cd $dirname; singletest)
  done
}

seq 100 | manytests

真正的脚本会做更多的错误检查、结果收集和总结。这find是我正在测试的实际程序的虚拟对象。

我想知道为什么我的文件系统密集型脚本在内存支持的文件系统上运行速度不快。是不是因为 linux 内核处理文件系统缓存的效率如此之高以至于它实际上是一个内存支持的文件系统？

Answer 1

一般而言，所有操作都首先在 RAM 中进行 - 文件系统被缓存。这条规则也有例外，但这些相当特殊的情况通常来自非常具体的要求。因此，在您开始执行缓存刷新之前，您将无法区分差异。

另一件事是，其性能取决于很多确切的文件系统上-有些是针对于大量的小文件更容易访问，有些是实时数据传输和从大文件（多媒体捕获/流），一些高效强调数据一致性，其他可以设计为具有较小的内存/代码占用空间。

回到您的用例：在一次循环中，您会生成大约 20 个新进程，其中大部分只创建一个目录/文件（请注意，()会为每个匹配项创建一个子 shell 并find生成cat）-瓶颈确实不是文件系统（如果您的系统使用ASLR并且您没有快速的熵源，您的系统随机池也会很快耗尽）。用 Perl 编写的 FUSE 也是如此——它不是这项工作的正确工具。