主页 / unix / 问题 / 529529
Accepted
sourcejedi
Asked: 2019-07-12 02:51:19 +0800 CST

为什么我的 IO 请求的大小被限制在 512K 左右？

  • 772

我/dev/sda使用 1MiB 块大小读取。Linux 似乎将 IO 请求限制为512KiB平均大小为 512KiB。这里发生了什么？这种行为是否有配置选项？

$ sudo dd iflag=direct if=/dev/sda bs=1M of=/dev/null status=progress
1545601024 bytes (1.5 GB, 1.4 GiB) copied, 10 s, 155 MB/s
1521+0 records in
1520+0 records out
...

当我的dd命令运行时，rareq-sz是 512。

Rareq-sz 向设备发出的读取请求的平均大小（以千字节为单位）。

--man iostat

$ iostat -d -x 3
...
Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
sda            309.00    0.00 158149.33      0.00     0.00     0.00   0.00   0.00    5.24    0.00   1.42   511.81     0.00   1.11  34.27
dm-0             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
dm-1             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
dm-2             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
dm-3             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
...

内核版本是5.1.15-300.fc30.x86_64. max_sectors_kb是1280。

$ cd /sys/class/block/sda/queue
$ grep -H . max_sectors_kb max_hw_sectors_kb max_segments max_segment_size optimal_io_size logical_block_size chunk_sectors
max_sectors_kb:1280
max_hw_sectors_kb:32767
max_segments:168
max_segment_size:65536
optimal_io_size:0
logical_block_size:512
chunk_sectors:0

默认情况下，我使用 BFQ I/O 调度程序。之后我也尝试重复测试echo 0 | sudo tee wbt_lat_usec。然后我也尝试在之后重复测试echo mq-deadline|sudo tee scheduler。结果保持不变。

除了 WBT，我对两个 I/O 调度程序都使用了默认设置。例如，对于mq-deadline,iosched/read_expire是 500，相当于半秒。

在最后一次测试期间（mq-deadline，WBT 禁用），我跑了btrace /dev/sda. 它显示所有请求被分成两个不相等的两半：

  8,0    0     3090     5.516361551 15201  Q   R 6496256 + 2048 [dd]
  8,0    0     3091     5.516370559 15201  X   R 6496256 / 6497600 [dd]
  8,0    0     3092     5.516374414 15201  G   R 6496256 + 1344 [dd]
  8,0    0     3093     5.516376502 15201  I   R 6496256 + 1344 [dd]
  8,0    0     3094     5.516388293 15201  G   R 6497600 + 704 [dd]
  8,0    0     3095     5.516388891 15201  I   R 6497600 + 704 [dd]
  8,0    0     3096     5.516400193   733  D   R 6496256 + 1344 [kworker/0:1H]
  8,0    0     3097     5.516427886   733  D   R 6497600 + 704 [kworker/0:1H]
  8,0    0     3098     5.521033332     0  C   R 6496256 + 1344 [0]
  8,0    0     3099     5.523001591     0  C   R 6497600 + 704 [0]

X -- split在[软件] RAID 或设备映射器设置中，传入的 i/o 可能跨越设备或内部区域，并且需要被分割成更小的部分以进行服务。这可能表明由于该 raid/dm 设备设置错误导致的性能问题，但也可能只是正常边界条件的一部分。dm 在这方面特别糟糕，会克隆很多 i/o。

--man blkparse

忽略的事情iostat

忽略%util号码。在这个版本中被破坏了。（`dd` 正在全速运行，但我只看到 20% 的磁盘利用率。为什么？）

我认为 由于基于 %utilaqu-sz也会受到影响。虽然我认为这意味着它在这里会大三倍（100/34.27）。

忽略svtm号码。“警告！不要再相信这个字段了。这个字段将在未来的 sysstat 版本中被删除。”

linux iostat

1 个回答

  1. Best Answer

    为什么我的 IO 请求的大小被限制在 512K 左右？

    我假设 I/O 被限制为“大约”512 KiB，因为它的提交方式和达到了各种限制（在这种情况下/sys/block/sda/queue/max_segments）。提问者花时间包含了各种辅助信息（例如内核版本和blktrace输出），这使我们能够猜测这个谜团，所以让我们看看我是如何得出这个结论的。

    为什么 [...] 限制在512K左右？

    关键是要注意提问者在标题中仔细地说了“关于”。虽然iostat输出让我们认为我们应该寻找 512 KiB 的值：

    Device         [...] aqu-sz rareq-sz wareq-sz  svctm  %util
sda            [...]   1.42   511.81     0.00   1.11  34.27

    blktrace(via ) 给了blkparse我们一些确切的值：

      8,0    0     3090     5.516361551 15201  Q   R 6496256 + 2048 [dd]
  8,0    0     3091     5.516370559 15201  X   R 6496256 / 6497600 [dd]
  8,0    0     3092     5.516374414 15201  G   R 6496256 + 1344 [dd]
  8,0    0     3093     5.516376502 15201  I   R 6496256 + 1344 [dd]
  8,0    0     3094     5.516388293 15201  G   R 6497600 + 704 [dd]
  8,0    0     3095     5.516388891 15201  I   R 6497600 + 704 [dd]

    （我们通常预计单个扇区的大小为 512 字节）因此，从dd扇区 6496256 读取的大小为 2048 个扇区（1 MiByte）的 I/O 被分成两部分 - 一个从扇区 6496256 开始读取 1344 个扇区，另一个读取从扇区 6497600 开始读取 704 个扇区。因此，请求拆分前的最大大小略大于 1024 个扇区（512 KiB） ……但为什么呢？

    提问者提到了一个内核版本5.1.15-300.fc30.x86_64。谷歌搜索 linux split block i/o kernel会出现Linux Device Drivers, 3rd Edition 中的“Chapter 16. Block Drivers”，其中提到

    [...]bio_split可用于将 a 拆分bio为多个块以提交给多个设备的调用

    虽然我们没有拆分bios，因为我们打算将它们发送到不同的设备（以 md 或设备映射器可能的方式），但这仍然为我们提供了一个探索的领域。搜索LXR 的 5.1.15 Linux 内核源代码中bio_split包含指向该文件的链接block/blk-merge.c。在该文件中blk_queue_split()，函数调用的非特殊 I/O 有blk_bio_segment_split().

    （如果你想休息一下，现在是探索 LXR 的好时机。我将继续下面的调查，并尝试更简洁地向前推进）

    在变量中最终来自对齐返回的值blk_bio_segment_split()，如果它是零，那么就返回。点击周围，我们看到是如何从in which is in派生的。回到里面，变量来自哪个returns 。继续往下看，我们看到以下内容：max_sectorsblk_max_size_offset()q->limits.chunk_sectorsq->limits.max_sectorsmax_sectorsmax_sectors_kbqueue_max_sectors_store()block/blk-sysfs.cblk_bio_segment_split()max_segsqueue_max_segments()q->limits.max_segmentsblk_bio_segment_split()

        bio_for_each_bvec(bv, bio, iter) {

    根据block/biovecs.txt我们正在迭代多页 bvec。

            if (sectors + (bv.bv_len >> 9) > max_sectors) {
            /*
             * Consider this a new segment if we're splitting in
             * the middle of this vector.
             */
            if (nsegs < max_segs &&
                sectors < max_sectors) {
                /* split in the middle of bvec */
                bv.bv_len = (max_sectors - sectors) << 9;
                bvec_split_segs(q, &bv, &nsegs,
                        &seg_size,
                        &front_seg_size,
                        &sectors, max_segs);
            }
            goto split;
        }

    因此，如果 I/O 大小大于max_sectors_kb（在提问者的情况下为 1280 KiB），它将被拆分（如果有备用段和扇区空间，那么我们将在拆分之前尽可能多地填充当前 I/O将其分成段并尽可能多地添加）。但在提问者的情况下，I/O“只有”1 MiB，小于 1280 KiB，所以我们不在这种情况下......再往下看：

            if (bvprvp) {
            if (seg_size + bv.bv_len > queue_max_segment_size(q))
                goto new_segment;
        [...]

    queue_max_segment_size()返回q->limits.max_segment_size。鉴于我们之前看到的一些内容 ( if (sectors + (bv.bv_len >> 9) > max_sectors))bv.bv_len将以字节为单位（否则为什么我们必须将其除以 512？）而提问者说/sys/block/sda/queue/max_segment_size的是 65336。如果我们知道什么是值bv.bv_len...

    [...]
new_segment:
        if (nsegs == max_segs)
            goto split;

        bvprv = bv;
        bvprvp = &bvprv;

        if (bv.bv_offset + bv.bv_len <= PAGE_SIZE) {
            nsegs++;
            seg_size = bv.bv_len;
            sectors += bv.bv_len >> 9;
            if (nsegs == 1 && seg_size > front_seg_size)
                front_seg_size = seg_size;
        } else if (bvec_split_segs(q, &bv, &nsegs, &seg_size,
                    &front_seg_size, &sectors, max_segs)) {
            goto split;
        }
    }

    do_split = false;

    因此，对于每个bv我们检查它是单页还是多页 bvec（通过检查其大小是否为 <= PAGE_SIZE）。如果它是单页 bvec，我们在段数上加一并做一些簿记。如果它是一个多页 bvec，我们检查它是否需要拆分成更小的段（在这种情况下，代码bvec_split_segs()会进行比较get_max_segment_size()，这意味着它将段拆分为不大于 64 KiB 的多个段（之前我们说/sys/block/sda/queue/max_segment_size是 65336）但是有必须不超过 168 ( max_segs) 段。如果bvec_split_segs()达到段限制并且没有覆盖 的所有bv长度，那么我们将跳转到split。但是，如果我们假设我们采取goto split如果我们只生成 1024 / 64 = 16 个段，所以最终我们不必提交少于 1 MiB I/O，所以这不是提问者的 I/O 所经过的路径......

    向后工作，如果我们假设“只有单页大小的段”，这意味着我们可以推断出bv.bv_offset + bv.bv_len<= 4096，因为bv_offsetis anunsigned int then 这意味着 0 <= bv.bv_len<= 4096。因此我们也可以推断出我们从未采用过条件体导致goto new_segment较早。然后我们继续得出结论，原始 biovec 必须有 1024 / 4 = 256 段。256 > 168 所以我们会在生成一个 168 个段的 I/O 和另一个 88 个段的 I/O之后导致跳转。splitnew_segment168 * 4096 = 688128 字节，88 * 4096 = 360448 字节但那又怎样？出色地：

    688128 / 512 = 1344

    360448 / 512 = 704

    blktrace我们在输出中看到的数字是：

    [...]   R 6496256 + 2048 [dd]
[...]   R 6496256 / 6497600 [dd]
[...]   R 6496256 + 1344 [dd]
[...]   R 6496256 + 1344 [dd]
[...]   R 6497600 + 704 [dd]
[...]   R 6497600 + 704 [dd]

    因此，我建议dd您使用的命令行导致 I/O 形成单页 bvecs，并且由于达到了最大段数，I/O 的分割发生在每个I/O 的672 KiB的边界处/O。

    我怀疑如果我们以不同的方式提交 I/O（例如，通过缓冲 I/O）以生成多页 bvecs，那么我们会看到不同的拆分点。

    这种行为是否有配置选项？

    排序 -/sys/block/<block device>/queue/max_sectors_kb是对通过块层提交的正常 I/O 在拆分之前可以达到的最大大小的控制，但它只是许多标准之一 - 如果达到其他限制（例如最大段），那么基于块的 I/O 可以以较小的大小进行拆分。此外，如果您使用原始 SCSI 命令，则可以提交最大/sys/block/<block device>/queue/max_hw_sectors_kb大小的 I/O，但是您绕过了块层，更大的 I/O 将被拒绝。

    实际上，您可以Ilya Dryomovmax_segments在 2015 年 6 月的 Ceph 用户线程“krbd 将大型 IO 拆分为较小的 IO”中描述此限制，并且后来对rbd设备进行了修复（它本身后来被修复）。

    内核块层维护者 Jens Axboe的题为“当 2MB 变成 512KB ”的文档进一步验证了上述内容，其中有一个题为“设备限制”的部分更简洁地涵盖了最大段限制。

    • 7

相关问题