☰

即使使用 nohup，在 bash 中启动“dd”在后台写入的延迟也很大

tag-icon • tag-icon linux bash dd write
即使使用 nohup，在 bash 中启动“dd”在后台写入的延迟也很大

我编写了一个小脚本来打印文件大规模连续写入过程中的内存使用情况。

#!/bin/bash
rm result
echo 3 > /proc/sys/vm/drop_caches
sync;
echo start
nohup time dd if=/dev/zero of=mem bs=1M count=2000 & 
for i in {1..200}
do
  sleep 0.2
  cat /proc/meminfo | grep Dirty >> result
  cat /proc/meminfo | grep Dirty
done
cat nohup.out
cat result

我应该从运行开始就看到“Dirty”大小的增加。但是当我运行脚本时，我经常看到很大的延迟（最多几秒钟），在此期间“Dirty”大小没有增加，这可能意味着“dd”程序的启动被延迟了。一个有问题的输出示例是：

Dirty:                20 kB
Dirty:                20 kB
Dirty:                20 kB
Dirty:                20 kB
Dirty:                20 kB
Dirty:                24 kB
Dirty:                24 kB
Dirty:                24 kB
Dirty:                24 kB
Dirty:                28 kB
Dirty:                28 kB
Dirty:                28 kB
Dirty:                28 kB
Dirty:                28 kB
Dirty:             16528 kB
Dirty:            140608 kB
Dirty:            277228 kB
Dirty:            311768 kB
Dirty:            434308 kB
Dirty:            563352 kB
Dirty:            690952 kB
...

延迟时间不确定，有时根本没有延迟。相比之下，当我运行

time dd if=/dev/zero of=mem bs=1M count=2000

使用一些实时的 meminfo 查看器，例如：

#!/bin/bash
clear
while true
do
  sleep 0.2
  tput home
  cat /proc/meminfo
done

我总是看到“Dirty”大小立即增加。我的脚本有问题吗？我还怀疑操作系统如何执行“写入”操作，因为我还测试了文件读取并检测了 /proc/meminfo 中的“Cached”字段，它似乎根本没有延迟。

谢谢，

答案1

nohup time dd if=/dev/zero of=mem bs=1M count=2000 &

你的系统上有“时间”二进制文件吗？否则 nohup 不知道如何自行运行 bash 内部程序，因此会失败

答案2

您可以通过以下方式调用脚本来确定占用了额外时间的内容

/bin/bash -x /path/to/script

并观察输出。这将打印脚本执行时的每一行代码。或者，您可以在每个命令前面加上 time 命令，这样就会很容易地看出哪些命令占用了额外的时间。

答案3

您能否重新启动系统并确保重新启动后至少从应用程序方面不会发生太多写入，现在尝试执行您的 dd 命令，原因是如果您想测试写入操作，系统应该是干净和稳定的。您的延迟将取决于您要使用哪种 fs 参数和文件系统类型。希望这会有所帮助。

相关内容