Linux AIO: плохое масштабирование

Я пишу библиотеку, которая использует системные вызовы асинхронного ввода-вывода Linux, и хотел бы знать, почему функция io_submit демонстрирует плохое масштабирование файловой системы ext4. Если возможно, что я могу сделать, чтобы io_submit не блокировать большие размеры запросов ввода-вывода? Я уже делаю следующее (как описано здесь):

• Используйте O_DIRECT.
• Совместите буфер ввода-вывода с 512-байтной границей.
• Установите размер буфера в несколько раз для размера страницы.

Чтобы узнать, сколько времени занимает ядро ​​в io_submit, я проверил тест, в котором я создал тестовый файл с 1 Гб, используя dd и /dev/urandom, и неоднократно удалял системный кеш (sync; echo 1 > /proc/sys/vm/drop_caches) и читать все более большие части файла. На каждой итерации я печатал время, затраченное на io_submit, и время, ожидаемое для завершения запроса на чтение. Я провел следующий эксперимент в системе x86-64 под управлением Arch Linux с версией ядра 3.11. Машина имеет SSD и процессор Core i7. На первом графике заканчивается количество прочитанных страниц с временем ожидания io_submit. Второй график отображает время ожидания ожидающего завершения запроса на чтение. Время измеряется в секундах.

Для сравнения, я создал аналогичный тест, который использует синхронный IO с помощью pread. Вот результаты:

Кажется, что асинхронный IO работает так, как ожидалось, чтобы запрашивать размеры около 20 000 страниц. После этого io_submit блокирует. Эти наблюдения приводят к следующим вопросам:

• Почему не время выполнения io_submit constant?
• Что вызывает это плохое масштабирование?
• Нужно ли мне разделить все запросы на чтение файловых систем ext4 на несколько запросов, каждый из которых составляет менее 20 000 страниц?
• Откуда эта "магическая" стоимость 20 000? Если я запускаю свою программу в другой системе Linux, как я могу определить самый большой размер запроса ввода-вывода для использования, не испытывая плохого поведения масштабирования?

Ниже приведен код, используемый для проверки асинхронного ввода-вывода. Я могу добавить другие списки источников, если вы считаете их релевантными, но я попытался опубликовать только те детали, которые, как я думал, могут иметь значение.

#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;
    }
}

Ответы

Ответ 1

Я понимаю, что очень немногие (если есть) файловые системы на Linux полностью поддерживают AIO. Некоторые операции файловой системы все еще блокируются, а иногда io_submit() косвенно через операции с файловой системой вызывают такие блокирующие вызовы.

Мое понимание заключается в том, что основные пользователи ядра AIO в первую очередь заботятся о том, что AIO действительно асинхронен на необработанных блочных устройствах (т.е. нет файловой системы). по сути, поставщики баз данных.

Вот соответствующее сообщение из списка рассылки linux-aio. (head потока)

Возможно полезная рекомендация:

Добавьте дополнительные запросы через /sys/block/xxx/queue/nr _requests и проблему будет лучше.

Ответ 2

Вам не хватает цели использовать AIO в первую очередь. В ссылочном примере показана последовательность операций [fill-buffer], [write], [write], [write],... [read], [read], [read],.... Фактически вы заполняете данные по трубе. В конце концов, труба заполняется, когда вы достигли предела пропускной способности ввода-вывода для вашего хранилища. Теперь вы заняты, ожидая, что проявляется в вашей линейной работе по снижению производительности.

Рост производительности для записи AIO заключается в том, что приложение заполняет буфер, а затем сообщает ядру начать операцию записи; управление возвращается к приложению немедленно, пока ядро ​​все еще владеет буфером данных и его содержимым; пока ядро ​​не завершит команду ввода-вывода, приложение не должно касаться буфера данных, потому что вы еще не знаете, какая часть (если таковая имеется) буфера фактически сделала его на носитель: измените буфер до ввода-вывода и вы повредили данные, выходящие на носитель.

И наоборот, выигрыш от чтения AIO - это когда приложение выделяет буфер ввода-вывода, а затем сообщает ядру начать заполнять буфер. Control немедленно возвращается в приложение, и приложение должно оставить буфер только до тех пор, пока ядро ​​не сообщит, что оно завершено буфером, отправив сообщение о завершении ввода-вывода.

Таким образом, поведение, которое вы видите, является примером быстрого заполнения конвейера для хранилища. В конце концов данные генерируются быстрее, чем хранилище может сосать данные, а производительность падает до линейности, в то время как конвейер заправляется так быстро, как он опустеет: линейное поведение.

В примерной программе используются вызовы AIO, но она по-прежнему является линейной программой остановки и ожидания.