linux - 为什么带有 'direct'(O_DIRECT)标志的dd这么快？

Question

Closed. This question does not meet Stack Overflow guidelines。它当前不接受答案。












想改善这个问题吗？更新问题，以便将其作为 on-topic用于堆栈溢出。

2年前关闭。



Improve this question




我有一台服务器，其RAID50配置为24个驱动器(两组，每组12个)，如果运行，则:

dd if=/dev/zero of=ddfile2 bs=1M count=1953 oflag=direct

我得到:

2047868928 bytes (2.0 GB) copied, 0.805075 s, 2.5 GB/s

但是如果我运行:

dd if=/dev/zero of=ddfile2 bs=1M count=1953

我得到:

2047868928 bytes (2.0 GB) copied, 2.53489 s, 808 MB/s

我了解O_DIRECT会导致页面缓存被绕过。但据我了解，绕过页面缓存基本上意味着避免使用memcpy。使用 bandwidth tool在我的桌面上进行测试，在最坏的情况下，我的连续内存写入带宽为14GB/s，并且我想在价格更高的新型服务器上，带宽必须更好。那么，为什么额外的memcpy会导致> 2倍的减速？使用页面缓存时，确实涉及更多内容吗？这是非典型的吗？

最佳答案

在oflag=direct情况下:

您使内核能够立即将数据写出，而不是填充缓冲区并等待达到阈值/超时(这反过来意味着数据不太可能在不相关数据的同步之后被阻止)。 。

您正在保存内核工作(没有从userland到内核的多余副本，无需执行大多数缓冲区高速缓存管理操作)。

在某些情况下，脏缓冲区的刷新速度快于它们的刷新速度，这将导致生成脏缓冲区的程序要等到缓解任意限制的压力(请参阅SUSE's "Low write performance on SLES 11/12 servers with large RAM")。

更一般而言，巨大的块大小(1 MB)可能大于RAID的块大小，因此I/O将在内核中拆分，而较小的部分将并行提交，因此足够大，以使您从缓冲写回中合并具有微小I/O的值(value)不高( exact point that the kernel will start splitting I/Os depends on a number of factors。此外，尽管RAID strip 大小可能大于1 MB，但内核对于硬件RAID并不总是知道这一点。对于软件RAID，内核可以有时会针对 strip 大小进行优化-例如，我所在的内核知道 md0设备的 strip 大小为4 MByte，并通过 /sys/block/md0/queue/optimal_io_size暗示它偏爱该大小的I/O)。

鉴于以上所有情况，如果您在原始缓冲副本中将单个CPU用尽，并且您的工作量没有从缓存/销售中受益，但是磁盘可以处理更多的吞吐量，那么随着CPU时间的增加， O_DIRECT复制应该会更快由于减少了内核开销，因此可用于用户空间/服务磁盘I/O。

So why would an extra memcpy cause a >2x slowdown? Is there really a lot more involved when using the page cache?

不仅涉及每个I/O 额外的memcpy ，还需要考虑所有必须维护的额外缓存机制。 explanation about how copying a buffer to the kernel isn't instantaneous and how page pressure can slow things down问题的答案中有一个漂亮的Linux async (io_submit) write v/s normal (buffered) write。但是，除非您的程序可以足够快地生成数据并且CPU如此过载，否则它不能足够快地送入磁盘，因此通常不会显示出来或无关紧要。

Is this atypical?

不，对于您使用的工作量，您的结果是非常典型的 。我想象如果块大小很小(例如512字节)，那将是一个非常不同的结果。

让我们比较一下fio的输出，以帮助我们理解这一点:

$ fio --bs=1M --size=20G --rw=write --filename=zeroes --name=buffered_1M_no_fsync
buffered_1M_no_fsync: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=2511MiB/s][r=0,w=2510 IOPS][eta 00m:00s]
buffered_1M_no_fsync: (groupid=0, jobs=1): err= 0: pid=25408: Sun Aug 25 09:10:31 2019
  write: IOPS=2100, BW=2100MiB/s (2202MB/s)(20.0GiB/9752msec)
[...]
  cpu          : usr=2.08%, sys=97.72%, ctx=114, majf=0, minf=11
[...]
Disk stats (read/write):
    md0: ios=0/3, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%

因此，使用缓冲我们以大约2.1 GBytes/s的速度写入数据，但是用尽了整个CPU的时间。但是，块设备(md0)表示几乎看不到任何I/O(ios=0/3-只有三个写入I/O)，这很可能意味着大部分I/O都缓存在RAM中!由于这台特定的机器可以轻松地在RAM中缓冲20 GB，因此我们将使用end_fsync=1进行另一轮运行，以强制将可能只在运行结束时位于内核RAM缓存中的所有数据 push 磁盘，从而确保我们记录了时间使所有数据实际到达非 Volatile 存储:

$ fio --end_fsync=1 --bs=1M --size=20G --rw=write --filename=zeroes --name=buffered_1M
buffered_1M: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [F(1)][100.0%][r=0KiB/s,w=0KiB/s][r=0,w=0 IOPS][eta 00m:00s]      
buffered_1M: (groupid=0, jobs=1): err= 0: pid=41884: Sun Aug 25 09:13:01 2019
  write: IOPS=1928, BW=1929MiB/s (2023MB/s)(20.0GiB/10617msec)
[...]
  cpu          : usr=1.77%, sys=97.32%, ctx=132, majf=0, minf=11
[...]
Disk stats (read/write):
    md0: ios=0/40967, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/2561, aggrmerge=0/2559, aggrticks=0/132223, aggrin_queue=127862, aggrutil=21.36%

好的，现在速度已降至约1.9 GBytes/s，我们仍然使用所有CPU，但RAID设备中的磁盘声称它们具有更快的容量(aggrutil=21.36%)。下一步直接I/O:

$ fio --end_fsync=1 --bs=1M --size=20G --rw=write --filename=zeroes --direct=1 --name=direct_1M 
direct_1M: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=3242MiB/s][r=0,w=3242 IOPS][eta 00m:00s]
direct_1M: (groupid=0, jobs=1): err= 0: pid=75226: Sun Aug 25 09:16:40 2019
  write: IOPS=2252, BW=2252MiB/s (2361MB/s)(20.0GiB/9094msec)
[...]
  cpu          : usr=8.71%, sys=38.14%, ctx=20621, majf=0, minf=83
[...]
Disk stats (read/write):
    md0: ios=0/40966, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/5120, aggrmerge=0/0, aggrticks=0/1283, aggrin_queue=1, aggrutil=0.09%

直接说来，我们使用不到50％的CPU来完成2.2 GB/s的速度(但是请注意，如何不合并I/O以及如何进行更多的用户空间/内核上下文切换)。如果我们要为每个系统调用增加更多的I/O，则情况将发生变化:

$ fio --bs=4M --size=20G --rw=write --filename=zeroes --name=buffered_4M_no_fsync
buffered_4M_no_fsync: (g=0): rw=write, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=2390MiB/s][r=0,w=597 IOPS][eta 00m:00s]
buffered_4M_no_fsync: (groupid=0, jobs=1): err= 0: pid=8029: Sun Aug 25 09:19:39 2019
  write: IOPS=592, BW=2370MiB/s (2485MB/s)(20.0GiB/8641msec)
[...]
  cpu          : usr=3.83%, sys=96.19%, ctx=12, majf=0, minf=1048
[...]
Disk stats (read/write):
    md0: ios=0/4667, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/292, aggrmerge=0/291, aggrticks=0/748, aggrin_queue=53, aggrutil=0.87%

$ fio --end_fsync=1 --bs=4M --size=20G --rw=write --filename=zeroes --direct=1 --name=direct_4M
direct_4M: (g=0): rw=write, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=5193MiB/s][r=0,w=1298 IOPS][eta 00m:00s]
direct_4M: (groupid=0, jobs=1): err= 0: pid=92097: Sun Aug 25 09:22:39 2019
  write: IOPS=866, BW=3466MiB/s (3635MB/s)(20.0GiB/5908msec)
[...]
  cpu          : usr=10.02%, sys=44.03%, ctx=5233, majf=0, minf=12
[...]
Disk stats (read/write):
    md0: ios=0/4667, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/292, aggrmerge=0/291, aggrticks=0/748, aggrin_queue=53, aggrutil=0.87%

由于块的大小为4 MB，缓冲的I/O成为“仅” 2.3 GBytes/s的瓶颈(即使当我们没有强制刷新高速缓存时)，这是因为实际上没有CPU了。直接I/O使用了大约55％的CPU，并设法达到3.5 GB/s，因此它比缓冲I/O快大约50％。

简介:您的I/O模式并没有真正从缓冲中受益(I/O很大，数据没有被重用，I/O是按顺序流式传输的)，因此您处于O_DIRECT更快的最佳方案。有关其背后的原始动机，请参见这些slides by the original author of Linux's O_DIRECT (更长的PDF document that contains an embedded version of most of the slides)。

关于linux - 为什么带有 'direct'(O_DIRECT)标志的dd这么快？ ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33485108/

上一篇：linux - 没有 NSURLRequest 的 Swift 中的 HTTP 请求

下一篇：linux - TCP 接收窗口大小高于 net.core.rmem_max

相关文章：

java - Android 文件不存在(但同时存在!)

perl - STDOUT 和 STDERR 乱序

linux - 修复文件权限以通过 php 代码在带有 lamp 设置的 Linux 服务器 centos 中读写访问鱿鱼配置

linux - 两个进程共享UDP socket，一个进程重启后停止接收消息

linux - Cygwin 串行端口权限被拒绝错误

c - gtk_entry_set_activates_default 没有发挥它的魔力

javascript - 当有多个同名文件时如何选择第一个文件输入

java - 读取文件中的特定信息

java - outputStream.write 有缓冲区溢出吗？

c - fscanf 和 fprintf 在 C 中缓冲吗？

Answer 1

在oflag=direct情况下:

您使内核能够立即将数据写出，而不是填充缓冲区并等待达到阈值/超时(这反过来意味着数据不太可能在不相关数据的同步之后被阻止)。 。

您正在保存内核工作(没有从userland到内核的多余副本，无需执行大多数缓冲区高速缓存管理操作)。

在某些情况下，脏缓冲区的刷新速度快于它们的刷新速度，这将导致生成脏缓冲区的程序要等到缓解任意限制的压力(请参阅SUSE's "Low write performance on SLES 11/12 servers with large RAM")。

更一般而言，巨大的块大小(1 MB)可能大于RAID的块大小，因此I/O将在内核中拆分，而较小的部分将并行提交，因此足够大，以使您从缓冲写回中合并具有微小I/O的值(value)不高( exact point that the kernel will start splitting I/Os depends on a number of factors。此外，尽管RAID strip 大小可能大于1 MB，但内核对于硬件RAID并不总是知道这一点。对于软件RAID，内核可以有时会针对 strip 大小进行优化-例如，我所在的内核知道 md0设备的 strip 大小为4 MByte，并通过 /sys/block/md0/queue/optimal_io_size暗示它偏爱该大小的I/O)。

鉴于以上所有情况，如果您在原始缓冲副本中将单个CPU用尽，并且您的工作量没有从缓存/销售中受益，但是磁盘可以处理更多的吞吐量，那么随着CPU时间的增加， O_DIRECT复制应该会更快由于减少了内核开销，因此可用于用户空间/服务磁盘I/O。

So why would an extra memcpy cause a >2x slowdown? Is there really a lot more involved when using the page cache?

不仅涉及每个I/O 额外的memcpy ，还需要考虑所有必须维护的额外缓存机制。 explanation about how copying a buffer to the kernel isn't instantaneous and how page pressure can slow things down问题的答案中有一个漂亮的Linux async (io_submit) write v/s normal (buffered) write。但是，除非您的程序可以足够快地生成数据并且CPU如此过载，否则它不能足够快地送入磁盘，因此通常不会显示出来或无关紧要。

Is this atypical?

不，对于您使用的工作量，您的结果是非常典型的 。我想象如果块大小很小(例如512字节)，那将是一个非常不同的结果。

让我们比较一下fio的输出，以帮助我们理解这一点:

$ fio --bs=1M --size=20G --rw=write --filename=zeroes --name=buffered_1M_no_fsync
buffered_1M_no_fsync: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=2511MiB/s][r=0,w=2510 IOPS][eta 00m:00s]
buffered_1M_no_fsync: (groupid=0, jobs=1): err= 0: pid=25408: Sun Aug 25 09:10:31 2019
  write: IOPS=2100, BW=2100MiB/s (2202MB/s)(20.0GiB/9752msec)
[...]
  cpu          : usr=2.08%, sys=97.72%, ctx=114, majf=0, minf=11
[...]
Disk stats (read/write):
    md0: ios=0/3, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%

因此，使用缓冲我们以大约2.1 GBytes/s的速度写入数据，但是用尽了整个CPU的时间。但是，块设备(md0)表示几乎看不到任何I/O(ios=0/3-只有三个写入I/O)，这很可能意味着大部分I/O都缓存在RAM中!由于这台特定的机器可以轻松地在RAM中缓冲20 GB，因此我们将使用end_fsync=1进行另一轮运行，以强制将可能只在运行结束时位于内核RAM缓存中的所有数据 push 磁盘，从而确保我们记录了时间使所有数据实际到达非 Volatile 存储:

$ fio --end_fsync=1 --bs=1M --size=20G --rw=write --filename=zeroes --name=buffered_1M
buffered_1M: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [F(1)][100.0%][r=0KiB/s,w=0KiB/s][r=0,w=0 IOPS][eta 00m:00s]      
buffered_1M: (groupid=0, jobs=1): err= 0: pid=41884: Sun Aug 25 09:13:01 2019
  write: IOPS=1928, BW=1929MiB/s (2023MB/s)(20.0GiB/10617msec)
[...]
  cpu          : usr=1.77%, sys=97.32%, ctx=132, majf=0, minf=11
[...]
Disk stats (read/write):
    md0: ios=0/40967, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/2561, aggrmerge=0/2559, aggrticks=0/132223, aggrin_queue=127862, aggrutil=21.36%

好的，现在速度已降至约1.9 GBytes/s，我们仍然使用所有CPU，但RAID设备中的磁盘声称它们具有更快的容量(aggrutil=21.36%)。下一步直接I/O:

$ fio --end_fsync=1 --bs=1M --size=20G --rw=write --filename=zeroes --direct=1 --name=direct_1M 
direct_1M: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=3242MiB/s][r=0,w=3242 IOPS][eta 00m:00s]
direct_1M: (groupid=0, jobs=1): err= 0: pid=75226: Sun Aug 25 09:16:40 2019
  write: IOPS=2252, BW=2252MiB/s (2361MB/s)(20.0GiB/9094msec)
[...]
  cpu          : usr=8.71%, sys=38.14%, ctx=20621, majf=0, minf=83
[...]
Disk stats (read/write):
    md0: ios=0/40966, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/5120, aggrmerge=0/0, aggrticks=0/1283, aggrin_queue=1, aggrutil=0.09%

直接说来，我们使用不到50％的CPU来完成2.2 GB/s的速度(但是请注意，如何不合并I/O以及如何进行更多的用户空间/内核上下文切换)。如果我们要为每个系统调用增加更多的I/O，则情况将发生变化:

$ fio --bs=4M --size=20G --rw=write --filename=zeroes --name=buffered_4M_no_fsync
buffered_4M_no_fsync: (g=0): rw=write, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=2390MiB/s][r=0,w=597 IOPS][eta 00m:00s]
buffered_4M_no_fsync: (groupid=0, jobs=1): err= 0: pid=8029: Sun Aug 25 09:19:39 2019
  write: IOPS=592, BW=2370MiB/s (2485MB/s)(20.0GiB/8641msec)
[...]
  cpu          : usr=3.83%, sys=96.19%, ctx=12, majf=0, minf=1048
[...]
Disk stats (read/write):
    md0: ios=0/4667, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/292, aggrmerge=0/291, aggrticks=0/748, aggrin_queue=53, aggrutil=0.87%

$ fio --end_fsync=1 --bs=4M --size=20G --rw=write --filename=zeroes --direct=1 --name=direct_4M
direct_4M: (g=0): rw=write, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=5193MiB/s][r=0,w=1298 IOPS][eta 00m:00s]
direct_4M: (groupid=0, jobs=1): err= 0: pid=92097: Sun Aug 25 09:22:39 2019
  write: IOPS=866, BW=3466MiB/s (3635MB/s)(20.0GiB/5908msec)
[...]
  cpu          : usr=10.02%, sys=44.03%, ctx=5233, majf=0, minf=12
[...]
Disk stats (read/write):
    md0: ios=0/4667, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/292, aggrmerge=0/291, aggrticks=0/748, aggrin_queue=53, aggrutil=0.87%

由于块的大小为4 MB，缓冲的I/O成为“仅” 2.3 GBytes/s的瓶颈(即使当我们没有强制刷新高速缓存时)，这是因为实际上没有CPU了。直接I/O使用了大约55％的CPU，并设法达到3.5 GB/s，因此它比缓冲I/O快大约50％。

简介:您的I/O模式并没有真正从缓冲中受益(I/O很大，数据没有被重用，I/O是按顺序流式传输的)，因此您处于O_DIRECT更快的最佳方案。有关其背后的原始动机，请参见这些slides by the original author of Linux's O_DIRECT (更长的PDF document that contains an embedded version of most of the slides)。