Почну з визнання, що я дуже не знаю про внутрішню роботу жорстких дисків. Тож коли я прочитав посібник для змінної innodb_flush_method , це мене збентежило. Чи можу я отримати пояснення в умовах непростого про різницю в O_DSYNC та O_DIRECT та як дізнатися, чи це проблема з продуктивністю на сервері баз даних.

Деякі статистичні дані в моїй установці: Mac OSX 10.6 (32-бітове ядро, оскільки архітектура застаріла), що працює з MySQL 5.1.49-64bit (сподіваючись, що це дозволить мені використовувати пам'ять). 8 ГБ оперативної пам’яті, ~ 6 ГБ даних / індексів innodb.

mysql innodb

— Дерек Дауні
джерело

Я не знаю, чи підтримує Mac OS X правильний варіант прямого вводу-виводу - я не вважав, що це так. Ти друга людина, яку я бачив сьогодні, плутається ця сторінка керівництва. У мене тут відкрита помилка: bugs.mysql.com/bug.php?id=54306

— Morgan Tocker

Ось пояснення щодо того, як fdatasync()працює проти того, як fsync()працює

fdatasync()видаляє всі буфери даних файлу на диск (до того, як системний виклик повернеться). Він нагадує, fsync()але не потребує оновлення метаданих, таких як час доступу. Програми, які отримують доступ до баз даних або файлів журналів, часто записують крихітний фрагмент даних (наприклад, один рядок у файлі журналу), а потім fsync()негайно дзвонять для того, щоб записані дані фізично зберігалися на жорсткому диску. На жаль, fsync()завжди буде ініціювати дві операції запису

одна операція запису для нещодавно записаних даних
одна операція запису з метою оновлення часу модифікації, що зберігається в inode

Якщо час модифікації не є частиною концепції транзакції, тоді fdatasync()можна використовувати, щоб уникнути зайвих операцій запису диска в дію.

По-англійськи, O_DSYNCце швидше, ніж O_DIRECTз моменту O_DIRECTвиклику fsync()двічі (один для журналів і один для даних) і fsync()перевіряє запис даних через дві операції запису. Використання O_DSYNCдзвінків fdatsync()та fsync(). Можна подумати fdatasync()як про асинхронність fsync()(не віршування даних).

Дивлячись на цифри, O_DSYNCчи є чотири операційні записи, два з яких перевірені, а fsync()чотири операції запису, після чого всі підтверджуються.

ВИСНОВОК

O_DSYNC
- швидше за O_DIRECT
- Дані можуть / можуть бути невідповідними через затримку або відверту збій
O_DIRECT
- більш стійкий
- дані узгоджуються
- природно повільніше

Я сподіваюся, що ця відповідь допомагає, і я сподіваюся, що я не погіршив для вас.

— RolandoMySQLDBA
джерело

Варто зазначити: O_DIRECT використовується лише у файлах простору таблиць, а не в журналах. Також - чи буде O_DIRECT корисним чи ні, залежить від обладнання. Я пов’язав помилку з відкритою документацією як коментар до запитання автора.

— Морган Токер

Дякую, що пояснили це, Морган. Я це виправлю.

— RolandoMySQLDBA

O_DSYNC - це синхронне записування, як можна зробити висновок, що швидше, ніж асинхронний + fsync?

— noonex

@noonex fdatasync () є синхронним для своїх даних, а не своїх метаданих. За інформацією informit.com/articles/article.aspx?p=23618&seqNum=5 ,

This means that in principal, fdatasync can execute faster than fsync because it needs to force only one disk write instead of two. However, in current versions of Linux, these two system calls actually do the same thing, both updating the file's modification time.

У той час, коли я писав своє повідомлення 3,5 роки тому, це було правдою, особливо з більш старими версіями Linux.

— RolandoMySQLDBA

@noonex За даними en.wikipedia.org/wiki/Sync_(Unix) ,

The related system call fsync() commits just the buffered data relating to a specified file descriptor. fdatasync() is also available to write out just the changes made to the data in the file, and not necessarily the file's related metadata.

(Останнє оновлення Wiki було 28 липня 2014 року).

— RolandoMySQLDBA

Роз'яснення змінної MySQL innodb_flush_method

ВИСНОВОК