☰

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

tag-icon • tag-icon linux iostat
为什么我的 IO 请求大小被限制为大约 512K？

我/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。

稀有-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——分裂在[软件] raid 或设备映射器设置中，传入的 I/O 可能跨越设备或内部区域，并且需要被分割成更小的部分以供服务。这可能表明由于 raid/dm 设备设置不当而出现性能问题，但也可能只是正常边界条件的一部分。 dm 在这方面尤其糟糕，会克隆大量 I/O。

--man blkparse

需要忽略的事情iostat

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

我想法 aqu-sz也受到影响由于基于 %util。尽管我认为这意味着这里的大小大约是原来的三倍（100/34.27）。

忽略这个svtm数字。 “警告！不要再信任该字段。该字段将在未来的 sysstat 版本中删除。”

答案1

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

我认为由于提交方式和达到的各种限制（在本例中/sys/block/sda/queue/max_segments），I/O 被限制为“大约”512 KiB。提问者花时间提供了各种辅助信息（例如内核版本和输出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为 2048 个扇区 (1 MiByte) 的扇区 6496256 读取 I/O 被分为两部分 - 一个从扇区 6496256 开始读取 1344 个扇区，另一个从扇区 6496256 开始读取 1344 个扇区从扇区 6497600 开始读取 704 个扇区。所以拆分前请求的最大大小略大于 1024 个扇区 (512 KiB)... 但为什么？

提问者提到了5.1.15-300.fc30.x86_64.做一个Google 搜索 linux split block i/o kernel出现Linux 设备驱动程序，第 3 版中的“第 16 章。块驱动程序”并提到

[...]bio_split可用于将文件分割bio成多个块以提交到多个设备的调用

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

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

blk_bio_segment_split()变量中max_sectors最终来自于对齐返回的值blk_max_size_offset()它会查看q->limits.chunk_sectors，如果为零，则返回q->limits.max_sectors。点击一下，我们可以看到max_sectors是如何从max_sectors_kbin派生出来的queue_max_sectors_store()这是在block/blk-sysfs.c。回到blk_bio_segment_split()，max_segs变量来自queue_max_segments()返回q->limits.max_segments.继续往下blk_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_offset是一个unsigned int那么这意味着 0 <= bv.bv_len<= 4096。因此我们还可以推断我们从未采用导致goto new_segment之前的条件体。然后我们继续得出结论，原始的 Biovec 一定有 1024 / 4 = 256 个段。 256 > 168 所以我们会造成跳到split紧接着new_segment从而生成一个 168 段的 I/O 和另一个 88 段的 I/O。 168 * 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 形成单页 bvec，并且由于已达到最大段数，因此 I/O 的分割发生在以下边界处672 KB对于每个 I/O。

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

是否有针对此行为的配置选项？

排序 -/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 Dryomov 描述了这一max_segments限制在 2015 年 6 月的 Ceph 用户线程“krbd splitting large IO's intosmaller IO's”和稍后修复rbd设备（哪个其本身后来被修复）。

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

相关内容