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 ответа

Популярные теги