Оптимизация для записи O_DIRECT

Question

Я пытаюсь написать приложение, которое нужно будет очень быстро записать на диск.Я достиг своей цели по производительности записи на диск, и это здорово.

Однако я заметил, что запись на диск так быстро использует много процессорного времени: одно ядро ​​максимально загружено, другое -на 80% и еще 2 на 10-20%.Итак, я слышал, что O_DIRECT может уменьшить потребление ресурсов ЦП, избегая всех этих копий в пространство ядра, а затем копировать на диск.

Я запустил небольшую тестовую программу, которая подтвердила это - загрузка ЦП снижается до 50% от одного ядра -намного лучше.

Однако, я никогда не получал такую ​​же пропускную способность, как при обычной записи, и чтобы сделать это быстрее, мне пришлось использовать действительно большой размер записи (что-то около 130 МБ!)

Итак, вопрос, я думаю:

• Есть ли лучший способ уменьшить загрузку ЦП, чем O_DIRECT для записи?или
• Как я могу получить пропускную способность, аналогичную той, которую получает ядро?

Моя среда - Linux, я использую RAID 50 и могу буферизовать записипока я не достигну оптимального размера записи.За один раз будет только один писатель.

Answer 1

Цитирование этой страницы :

С O_DIRECT ядро ​​будет выполнять DMA напрямую из / в физическую память, указанную [на] буфером пространства пользователя, переданным как параметр [a]к системным вызовам чтения / записи.Таким образом, не будет расходоваться пропускная способность ЦП и памяти в копиях между пользовательской памятью и кэшем ядра, и не будет затрачиваться процессорное время в ядре на управление кешем (например, поиск в кеше, блокировки страниц и т. Д.).

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

Короче говоря: с O_DIRECT вам придется самостоятельно выполнять кэширование и другую оптимизацию, которая увеличивает пропускную способность.Огромный размер записи теперь не кажется таким странным.

Я не знаю других методов, но я не гуру Linux.Не стесняйтесь спрашивать вокруг:)

Answer 2

Вам нужно как-то организовать одновременное сохранение большего количества операций ввода-вывода и отправить их в оптимальном размере.Когда ядро ​​буферизует ваши входы / выходы записи вместе, это может принести ряд преимуществ:

• Может оказаться возможным объединить смежные входы / выходы вместе в более крупные входы / выходы.Если это так, то есть возможность сэкономить накладные расходы, потому что вместо того, чтобы отправлять 8 маленьких 4-килобайтных операций ввода-вывода вниз, ядро ​​теперь может отправлять 1 64-килобайтные операции ввода-вывода (например).
• Это открывает возможность параллельной отправки.,Если ядро ​​способно пакетировать до 256 Кбайт, теперь оно может отправить его как 8 одновременных операций ввода-вывода, таким образом достигая более высокой скорости iodepth.

Итак

IsЕсть ли лучший способ уменьшить загрузку ЦП, чем O_DIRECT для записи?

Да отправлять более крупные операции ввода-вывода до оптимального размера, предпочитаемого вашим диском.

Как я могуполучить пропускную способность, аналогичную той, которую получает ядро?

В идеале выполните вышеперечисленное (отправьте операции ввода-вывода оптимального размера) и убедитесь, что максимальное количество операций ввода-вывода, которые нравятся вашему диску, сохраняется сразу же (например, отправляя асинхронно или через несколько потоков / процессов, если вы собираетесь использовать процедуры блокировки), и отправляйте операции ввода-вывода в порядке LBA диска.Немного менее оптимальный трюк состоит в том, чтобы отправить огромные операции ввода-вывода и заставить ядро ​​разделить их для создания параллелизма, но это менее оптимально.

Answer 3

Вы пробовали с mmap и msync?Я не знаю, является ли он более быстрым или менее интенсивным процессором, но так как он представляет собой совершенно другой подход к вводу / выводу (в основном это ядро, которое выполняет ввод / вывод для вас), это может быть интересным местом.