Linux AIO：扩展性差

Posted 2023-02-22

技术标签:

【中文标题】Linux AIO：扩展性差【英文标题】：Linux AIO: Poor Scaling 【发布时间】：2014-01-07 14:09:02 【问题描述】：

我正在编写一个使用 Linux 异步 I/O 系统调用的库，并且想知道为什么 io_submit 函数在 ext4 文件系统上的扩展性较差。如果可能，我该怎么做才能让io_submit 不阻止大 IO 请求大小？我已经做了以下事情（如here 所述）：

使用O_DIRECT。将 IO 缓冲区对齐到 512 字节边界。将缓冲区大小设置为页面大小的倍数。

为了观察内核在io_submit 中花费了多长时间，我运行了一个测试，其中我使用dd 和/dev/urandom 创建了一个1 Gb 的测试文件，并反复删除了系统缓存（sync; echo 1 > /proc/sys/vm/drop_caches）并读取文件的越来越大的部分。在每次迭代中，我打印了io_submit 花费的时间以及等待读取请求完成所花费的时间。我在运行 Arch Linux 的 x86-64 系统上运行了以下实验，内核版本为 3.11。该机器具有 SSD 和 Core i7 CPU。第一张图绘制了阅读的页数与等待io_submit 完成所花费的时间。第二个图表显示等待读取请求完成所花费的时间。时间以秒为单位。

为了比较，我创建了一个类似的测试，它通过pread 使用同步IO。结果如下：

似乎异步 IO 按预期工作，请求大小约为 20,000 个页面。之后，io_submit 块。这些观察导致以下问题：

为什么io_submit的执行时间不是常数？是什么导致了这种不良的缩放行为？是否需要将 ext4 文件系统上的所有读取请求拆分为多个请求，每个请求的大小小于 20,000 页？ 20,000 这个“神奇”值从何而来？如果我在另一个 Linux 系统上运行我的程序，我如何才能确定要使用的最大 IO 请求大小而不会遇到糟糕的扩展行为？

用于测试异步 IO 的代码如下。如果您认为其他来源列表相关，我可以添加它们，但我尝试仅发布我认为可能相关的详细信息。

#include <cstddef>
#include <cstdint>
#include <cstring>
#include <chrono>
#include <iostream>
#include <memory>
#include <fcntl.h>
#include <stdio.h>
#include <time.h>
#include <unistd.h>
// For `__NR_*` system call definitions.
#include <sys/syscall.h>
#include <linux/aio_abi.h>

static int
io_setup(unsigned n, aio_context_t* c)

    return syscall(__NR_io_setup, n, c);


static int
io_destroy(aio_context_t c)

    return syscall(__NR_io_destroy, c);


static int
io_submit(aio_context_t c, long n, iocb** b)

    return syscall(__NR_io_submit, c, n, b);


static int
io_getevents(aio_context_t c, long min, long max, io_event* e, timespec* t)

    return syscall(__NR_io_getevents, c, min, max, e, t);


int main(int argc, char** argv)

    using namespace std::chrono;
    const auto n = 4096 * size_t(std::atoi(argv[1]));

    // Initialize the file descriptor. If O_DIRECT is not used, the kernel
    // will block on `io_submit` until the job finishes, because non-direct
    // IO via the `aio` interface is not implemented (to my knowledge).
    auto fd = ::open("dat/test.dat", O_RDONLY | O_DIRECT | O_NOATIME);
    if (fd < 0) 
        ::perror("Error opening file");
        return EXIT_FAILURE;
    

    char* p;
    auto r = ::posix_memalign((void**)&p, 512, n);
    if (r != 0) 
        std::cerr << "posix_memalign failed." << std::endl;
        return EXIT_FAILURE;
    
    auto del = [](char* p)  std::free(p); ;
    std::unique_ptr<char[], decltype(del)> bufp, del;

    // Initialize the IO context.
    aio_context_t c0;
    r = io_setup(4, &c);
    if (r < 0) 
        ::perror("Error invoking io_setup");
        return EXIT_FAILURE;
    

    // Setup I/O control block.
    iocb b;
    std::memset(&b, 0, sizeof(b));
    b.aio_fildes = fd;
    b.aio_lio_opcode = IOCB_CMD_PREAD;

    // Command-specific options for `pread`.
    b.aio_buf = (uint64_t)buf.get();
    b.aio_offset = 0;
    b.aio_nbytes = n;
    iocb* bs[1] = &b;

    auto t1 = high_resolution_clock::now();
    auto r = io_submit(c, 1, bs);
    if (r != 1) 
        if (r == -1) 
            ::perror("Error invoking io_submit");
        
        else 
            std::cerr << "Could not submit request." << std::endl;
        
        return EXIT_FAILURE;
    
    auto t2 = high_resolution_clock::now();
    auto count = duration_cast<duration<double>>(t2 - t1).count();
    // Print the wait time.
    std::cout << count << " ";

    io_event e[1];
    t1 = high_resolution_clock::now();
    r = io_getevents(c, 1, 1, e, NULL);
    t2 = high_resolution_clock::now();
    count = duration_cast<duration<double>>(t2 - t1).count();
    // Print the read time.
    std::cout << count << std::endl;

    r = io_destroy(c);
    if (r < 0) 
        ::perror("Error invoking io_destroy");
        return EXIT_FAILURE;

【问题讨论】：

您是否对旧内核版本进行了相同的测试？例如3.4？我这么说只是为了确保这不是由于内核中最近出现的尚未发现的错误造成的。 @Shahbaz 不，还没有——感谢您的建议。我会这样做并在这里再次发布。我不明白你的图表。它看起来像 20K 页面后的 AIO以恒定时间运行，而不是块。 @n.m.是的，看起来大部分的IO都是在io_submit函数中完成的，这就是阻塞。 “等待读取请求完成所花费的时间”是指等待io_getevents 返回所花费的时间。但由于 io_submit 是线性缩放 w.r.t。请求大小，io_getevents 将在恒定时间内返回是有道理的。我在描述某事时犯了错误吗？啊，我明白了。您的第二张图仅适用于 io_getevents。现在很清楚了。 【参考方案1】：

我的理解是，Linux 上很少（如果有的话）文件系统完全支持 AIO。一些文件系统操作仍然阻塞，有时io_submit() 会通过文件系统操作间接调用这种阻塞调用。

我的进一步理解是，内核 AIO 的主要用户主要关心 AIO 在原始块设备（即没有文件系统）上真正异步。本质上是数据库供应商。

Here's 来自 linux-aio 邮件列表的相关帖子。（线程的head）

一个可能有用的建议：

通过 /sys/block/xxx/queue/nr_requests 添加更多请求和问题会好起来的。

【讨论】：

【参考方案2】：

为什么io_submit的执行时间不是常数？

因为您提交的 I/O 非常大，所以块层必须将它们拆分，然后将生成的请求排队。这可能会导致您遇到资源限制，进而导致io_submit() 表现得好像它正在阻塞......

是什么导致了这种不良的缩放行为？

I/O 越大，超过拆分阈值（见下文），为将其转换为适当大小的请求而进行的拆分次数也就越有可能增加（可能实际上进行拆分会花费少量也是时间）。使用直接 I/O io_submit() 直到其所有请求都已分配并在块层级别排队时才会返回。此外，给定磁盘的块层可以排队的请求数量限制为/sys/block/[disk_device]/queue/nr_requests。超过此限制会导致io_submit() 阻塞，直到释放了足够的请求槽以使其所有分配都得到满足（这与Arvid was recommending 有关）。

是否需要将 ext4 文件系统上的所有读取请求拆分为多个请求，每个请求的大小小于 20,000 页？

理想情况下，您应该将您的请求分成比这小得多的数量 - 20000 个页面（假设 x86 平台上使用的页面为 4096 字节）大约为 78 兆字节！这不仅适用于您使用 ext4 时 - 对其他文件系统甚至直接对块设备执行如此大的 io_submit() I/O 大小不太可能表现良好。

如果您确定您的文件系统在哪个磁盘设备上并查看/sys/block/[disk_device]/queue/max_sectors_kb，这将为您提供一个上限，但bound at which splitting starts may be even smaller 因此您可能希望将每个 I/O 的大小限制为 /sys/block/[disk_device]/queue/max_segments * PAGE_SIZE .

20000 这个“神奇”值从何而来？

这可能归结为以下因素的某种组合：

在块层拆分之前每个 I/O 可以达到的最大大小（最多为 /sys/block/[disk_device]/queue/max_sectors_kb 但observed split limit may be even lower）在发生阻塞之前可以排队的最大 I/O 数 (/sys/block/[disk_device]/queue/nr_requests) 硬件的命令队列深度 (/sys/block/[disk_device]/device/queue_depth) 您的磁盘完成请求的速度。当内核无法再对真实设备的 I/O 进行排队时（由于硬件 queue_depth 已满且内核的附加队列已满），它会阻塞新请求，直到进入发送到硬件的航班已完成。

如果我在另一个 Linux 系统上运行我的程序，我如何才能确定要使用的最大 IO 请求大小而不会遇到不良的扩展行为？

将每个请求 I/O 限制为 /sys/block/[disk_device]/queue/max_sectors_kb 或 /sys/block/[disk_device]/queue/max_segments * PAGE_SIZE 中的较低值。我认为不大于 524288 字节的 I/O 应该是安全的，但您的硬件可能能够处理更大的大小，从而获得更高的吞吐量，但可能会以完成（而不是提交）延迟为代价。

如果可能，我可以做些什么来让 io_submit 不阻塞大型 IO 请求？

会有一个“好的”上限，如果你超过它，就会产生你无法逃避的后果。

Linux AIO：扩展性差

相关问题