Використання O_DIRECT в Linux

Якщо це питання занадто орієнтоване на програмування, дайте мені знати. Цікаво, чи є люди, знайомі з прапором O_DIRECT для системного виклику open () на Linux 2.6? Лінус зневажає його використання, проте, як видається, написання файлів високої продуктивності вказує на його використання. Я хотів би знати про будь-який реальний досвід та рекомендації у світі.

Більше інформації: Додаток, який я використовую , підтримує власний кеш, і при цьому набирає в середньому 5-кратну або більше прискорення. Під час запису у файл вміст кешу повинен бути записаний у кеш файлової системи, що здається зайвим і викликає занепокоєння у роботі.

Гаразд, ви запитуєте досвід, це робить питання трохи суб'єктивним та аргументативним, але прохідним.

Лінус сказав, що посилаючись на способи використання, які люди зазвичай приписують O_DIRECT, і для цих цілей IMO Linus здебільшого вірно. Навіть якщо ви робите прямий ввід / вивід, ви не можете передавати дані на / з пристроїв безпосередньо до програмних заяв, вам потрібен буфер, який заповнюється (програмою чи пристроєм) і передається через системний виклик на інший кінець. Крім того, щоб зробити його ефективним, ви не хочете перечитувати щось, що ви вже прочитали, якщо вам це буде потрібно знову. Тож вам потрібен якийсь кеш ... і саме це ядро ​​надає без O_DIRECT, кеш сторінки! Чому б не використати це? Він також отримує переваги, якщо більшість процесів хочуть одночасно отримувати доступ до одного файлу, це буде катастрофою з O_DIRECT.

Сказавши це, O_DIRECT використовує: Якщо з якихось причин вам потрібно отримати дані безпосередньо з блокового пристрою. Це не має нічого спільного з продуктивністю.

Люди, які використовують O_DIRECT для продуктивності, зазвичай походять із систем з алгоритмами кешування поганих сторінок або без механізмів поради POSIX, або навіть люди бездумно повторюють те, що сказали інші. Щоб уникнути цих проблем, O_DIRECT був рішенням. Linux, OTOH, має філософію, що слід виправити реальну основну проблему, а основна проблема - ОС, які погано спрацювали з кешуванням сторінок.

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

Насправді, O_DIRECT це потрібно, щоб уникнути жодного з

• забруднення кешу - іноді ви знаєте, що немає сенсу надмірних витрат з кешуванням, наприклад, наприклад, при роботі з дійсно великими файлами, скажімо, 64 GiB, коли є лише 2 ГБ оперативної пам’яті. Торрент-файл розміром 32 GiB, який користувач вирішив перевірити, здається, не є хорошим кандидатом на кешування. Це просто додаткова активність із власними накладними витратами. І це може призвести до викреслення деяких дійсно корисних даних із кешу.
• подвійне кешування - наприклад, деякі RDBMSes (згадайте MySQL) дозволяє визначити власний кеш. Бази даних нібито краще знають, як кешувати і що, ніж віртуальна пам'ять ядра, яка нічого не знає про планування SQL тощо.

- що не добре, як здається. І O_DIRECTне означає бути швидшим, часто це не так .

Зверніть увагу, що використання O_DIRECTнових ядер із новішими файловими системами може призвести до відмови. Наприклад, дивіться цей звіт про помилку . Тож використання не тільки часто сумнівне, воно, ймовірно, не спрацює у майбутньому поколінні дистрибутивів Linux. Тож я не ставлю ставку на виконання свого коду, навіть якщо ви зможете довести, що це може мати користь.

Це має багато спільного з продуктивністю.

Цікавий приклад - у mongodb із використанням двигуна mmap. O_DIRECT найкраще використовувати, як заявили інші, де дані навряд чи читатимуться деякий час. У mongodb журнал бази даних пишеться за допомогою O_DIRECT, тоді як записи даних та індексів обробляються механізмом кешування сторінок (pdflush), оскільки, хоча O_DIRECT пропонує меншу пропускну здатність, це також означає меншу затримку, а отже, зменшує втрату даних у випадку несподіване відключення (паніка ядра, збій диска або живлення). Зауважте, що ще існує буферизація, перш ніж запис O_DIRECT буде здійснено для енергонезалежного зберігання, це просто зменшує втрату даних.

Ще одна важлива особливість O_DIRECT полягає в тому, що він забезпечує більший контроль над послідовністю запису. Знову ж таки, це не гарантує порядок запису (якщо ви не маєте енергонезалежного контролера дискового кешування і не використовуєте планувальник fifo, але у них є свої ускладнення). Отже, хоча mysql використовує O_DIRECT для своїх даних / індексів, а також журналів, можна очікувати, що останній буде вчинений першим.

Але важливо пам’ятати, що O_DIRECT порушує справедливість у розподілі ресурсів. Однією з причин прискорення вашої заявки є те, що вона сповільнює інші речі.

Що стосується того, що @Juliano вже сказав.

Перевірте, posix_fadviseчи справжньою проблемою є неправильне поведінка основного алгоритму кешування файлової системи, ви можете спробувати дати йому поради, як ви будете використовувати файлову систему. Для добре реалізованих fs він повинен дати підвищення продуктивності. (Тут посилання на іншу тему, що стосується подібних міркувань /programming//a/3755818/544721 )