innodb_flush_method = O_DIRECT против воздействия производительности O_DSYNC на ext3 с дисковым разделом LVM
В одной из моих производственных сред у нас есть два экземпляра, запущенных в кластере RedHat, с одним производственным экземпляром, связанным с кластером.
У нас есть основная память 125G с 24G пулом буферов InnoDB, занятая экземпляром 1 & 12G, занятый экземпляром2, который не связан с кластером RedHat. Журналы данных и транзакций расположены на дисковой секции LVM с файловой системой ext3.
Для повышения производительности и улучшения пропускной способности ввода-вывода я решил изменить innodb_flush_method
на O_DIRECT
В отношении документации MySQL:
Если данные и файлы журнала InnoDB расположены в SAN, было установлено, что установка
innodb_flush_method
наO_DIRECT
может снизить производительность простых операторовSELECT
в три раза.
Ссылаясь на высокопроизводительные MySQL версии 2 и 3, он заявил, что разработчики InnoDB обнаружили ошибки с использованием innodb_flush_method=O_DSYNC
. O_SYNC
и O_DSYNC
похожи на fsync()
и fdatasync()
: O_SYNC
синхронизирует данные и метаданные, тогда как O_DSYNC
синхронизирует данные.
Если это все показалось многим объяснением без советов, вот совет:
, если вы используете Unix-подобную операционную систему, а ваш RAID-контроллер имеет резервную копию с батарейкой, мы рекомендуем использовать
O_DIRECT
, Если нет, то по умолчанию илиO_DIRECT
, вероятно, будет лучшим выбором, в зависимости от вашего приложения.
По googling я получил это сообщении :
Все еще есть небольшая путаница в обоих этих параметрах. Где я мог видеть большинство шаблонов конфигурации производства, используя
O_DSYNC
, я не видел никаких рекомендаций, рекомендующихO_DIRECT
Система
- MySQL 5.1.51-enterprise-gpl-pro-log
- Red Hat Enterprise Linux Server версии 5.5
- DELL DRAC с контроллером Raid, имеющим кэш обратной записи аккумулятора 512 МБ
- Контроллеры Dell PERC H700 с блоком резервной батареи (BBU).
Дополнительная информация
MySQL > показать переменные типа 'innodb_thread_concurrency'; + --------------------------- + ------- + | Variable_name | Значение | + --------------------------- + ------- + | innodb_thread_concurrency | 96 | + --------------------------- + ------- + 1 строка в наборе (0,00 сек) MySQL > показывать переменные типа «innodb_read_io_threads»; Пустой набор (0,00 сек) MySQL > показывать переменные типа «innodb_write_io_threads»; Пустой набор (0,00 сек)
Мы используем плагин по умолчанию, поэтому я опубликовал информацию из состояния InnoDB:
MySQL > SELECT * FROM Plugins WHERE PLUGIN_NAME LIKE '% innodb%' И PLUGIN_TYPE LIKE «ХРАНЕНИЕ ДВИГАТЕЛЯ» \ G *************************** 1. строка ******************** ******* PLUGIN_NAME: InnoDB PLUGIN_VERSION: 1.0 PLUGIN_STATUS: ACTIVE PLUGIN_TYPE: ХРАНЕНИЕ ДВИГАТЕЛЯ PLUGIN_TYPE_VERSION: 50151.0 PLUGIN_LIBRARY: NULL PLUGIN_LIBRARY_VERSION: NULL PLUGIN_AUTHOR: Innobase OY PLUGIN_DESCRIPTION: поддерживает транзакции, блокировку на уровне строк и внешние ключи PLUGIN_LICENSE: GPL 1 строка в наборе (0,00 сек)
2 ответа
Назад 21 января 2009 года Питер Зайцев заявил следующее на mysqlperformanceblog.com
Как призыв к действию - я бы очень хотел, чтобы кто-то увидел, может ли EXT3 быть исправлен в этом отношении, поскольку это, безусловно, самая распространенная файловая система для Linux. Также стоит исследовать, можно ли что-то сделать на стороне MySQL - может быть открытие binlog с флагом
O_DSYNC
, еслиsync_binlog=1
вместо использования fsync поможет? Или может быть предварительное выделение binlog будет хорошим решением.
В то же время я знаю, что никто не затронул эту проблему. O_DSYNC
по умолчанию не является привлекательной перспективой, но поддерживает более быстрые записи, которые на самом деле не проверены. Вот почему так много шумихи вокруг O_DIRECT
.
Я могу сказать, что у вас не установлен плагин InnoDB. С плагином InnoDB должно существовать несколько переменных.
Вы должны обновить InnoDB одним из двух способов:
- Обновление до MySQL 5.5 (все расширения плагина InnoDB являются частью MySQL 5.5)
- обновить плагин InnoDB
Как только вы это сделаете, вы можете увеличить InnoDB до
- доступ к более процессорам и ядрам
- увеличить потоки ввода-вывода для чтения и записи
- масштабировать емкость ввода /вывода (это особенно необходимо для разных носителей)
Вот мои прошлые сообщения о настройках, которые вы можете изменить для этого:
-
Sep 12, 2011
: Можно ли использовать MySQL более чем для одного ядра? -
Sep 20, 2011
: Множественные ядра и производительность MySQL -
Apr 26, 2012
: Является ли производительность процессора релевантной для сервера базы данных? -
Mar 16, 2012
: Использование нескольких ядер для одиночных запросов MySQL в Debian
Мне всегда казалось, что O_DIRECT
лучше для производительности, так как он предотвращает двойную буферизацию. Кроме того, если у вас есть аппаратный RAID с кешем записи с батареей. Конечно, это также зависит от рабочей нагрузки, будь вы READ или WRITE тяжелым.
Кроме того, вопрос для экспертов: выполните дополнительные вызовы fsync()
для O_DIRECT
вызывают заметное ухудшение общей производительности или это незначительно? Я еще не видел, что тесты показывают это.
Кроме того, обратите внимание, что Percona позволила установить innodb_flush_method=ALL_O_DIRECT
, который обеспечивает прямой ввод-вывод не только в файлах данных InnoDB, но также и в журналах транзакций InnoDB.