Позвольте мне начать с признания, что я очень не осведомлен о внутренней работе жестких дисков. Поэтому, когда я перечитал руководство по переменной 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

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

Вот объяснение того, как fdatasync()работает против того, как fsync()работает

fdatasync()сбрасывает все буферы данных файла на диск (до возврата системного вызова). Это напоминает, fsync()но не требуется для обновления метаданных, таких как время доступа. Приложения, которые обращаются к базам данных или файлам журналов, часто записывают крошечный фрагмент данных (например, одну строку в файле журнала), а затем fsync()немедленно вызывают , чтобы убедиться, что записанные данные физически хранятся на жестком диске. К сожалению, fsync()всегда будут инициировать две операции записи

одна операция записи для вновь записанных данных
одна операция записи для обновления времени модификации, хранящегося в индексе

Если время модификации не является частью концепции транзакции, то fdatasync()ее можно использовать, чтобы избежать ненужных операций записи на диск inode.

В английском языке, 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.

(последнее обновление Вики состоялось 28 июля 2014 г.).

— RolandoMySQLDBA

Разъяснение по переменной MySQL innodb_flush_method

ВЫВОД