17

我正在编写一个使用 Linux 异步 I/O 系统调用的库,并且想知道为什么该io_submit函数在 ext4 文件系统上表现出较差的扩展性。如果可能,我该怎么做才能io_submit不阻塞大 IO 请求大小?我已经做了以下事情(如此所述):

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

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

在此处输入图像描述

在此处输入图像描述

为了比较,我创建了一个类似的测试,它通过pread. 结果如下:

在此处输入图像描述

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

  • 为什么不是io_submit常量的执行时间?
  • 是什么导致了这种不良的缩放行为?
  • 我是否需要将 ext4 文件系统上的所有读取请求拆分为多个请求,每个请求的大小小于 20,000 页?
  • 20000这个“神奇”值从何而来?如果我在另一个 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)> buf{p, del};

    // Initialize the IO context.
    aio_context_t c{0};
    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;
    }
}
4

3 回答 3

5

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

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

这是来自 linux-aio 邮件列表的相关帖子。(线程的头部)

一个可能有用的建议:

通过 /sys/block/xxx/queue/nr_requests 添加更多请求,问题就会好转。

于 2014-01-08T00:43:56.297 回答
2

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

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

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

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

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

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

如果您计算出您的文件系统在哪个磁盘设备上并查看/sys/block/[disk_device]/queue/max_sectors_kb它会给您一个上限,但拆分开始的界限可能会更小,因此您可能希望限制每个 I/O 的大小/sys/block/[disk_device]/queue/max_segments * PAGE_SIZE

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

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

  • 在块层拆分之前每个 I/O 可以达到的最大大小(最多会是/sys/block/[disk_device]/queue/max_sectors_kb,但观察到的拆分限制可能会更低
  • 阻塞发生前可排队的最大 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 请求大小?

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

相关问题

Ubuntu Linux 中的异步 IO io_submit 延迟

于 2020-01-01T06:49:41.233 回答
0

您首先错过了使用 AIO 的目的。引用的示例显示了 [fill-buffer]、[write]、[write]、[write]、... [read]、[read]、[read]、... 操作的序列。实际上,您正在将数据填充到管道中。最终,当您达到存储的 I/O 带宽限制时,管道会填满。现在你正忙着等待,这显示在你的线性性能下降行为上。

AIO 写入的性能提升是应用程序填充缓冲区,然后告诉内核开始写入操作;当内核仍然拥有数据缓冲区及其内容时,控制权立即返回给应用程序;在内核发出 I/O 完成信号之前,应用程序不得接触数据缓冲区,因为您还不知道缓冲区的哪一部分(如果有)实际上已进入媒体:在 I/O 之前修改缓冲区完成并且您已经损坏了输出到媒体的数据。

相反,AIO 读取的好处是应用程序分配 I/O 缓冲区,然后告诉内核开始填充缓冲区。控制权立即返回给应用程序,应用程序必须不理会缓冲区,直到内核通过发布 I/O 完成事件来表示它已完成缓冲区。

因此,您看到的行为是快速将管道填充到存储的示例。最终,数据的生成速度比存储能够吸收数据的速度更快,并且性能下降到线性,而管道在清空时会尽快重新填充:线性行为。

示例程序确实使用了 AIO 调用,但它仍然是一个线性停止等待程序。

于 2014-04-02T14:25:47.633 回答