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 сек)
11 голосов | спросил Gopinath 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 09 Sep 2012 09:17:32 +0400 2012, 09:17:32

2 ответа


6

Назад 21 января 2009 года Питер Зайцев заявил следующее на mysqlperformanceblog.com

  

Как призыв к действию - я бы очень хотел, чтобы кто-то увидел, может ли EXT3 быть исправлен в этом отношении, поскольку это, безусловно, самая распространенная файловая система для Linux. Также стоит исследовать, можно ли что-то сделать на стороне MySQL - может быть открытие binlog с флагом O_DSYNC, если sync_binlog=1 вместо использования fsync поможет? Или может быть предварительное выделение binlog будет хорошим решением.

В то же время я знаю, что никто не затронул эту проблему. O_DSYNC по умолчанию не является привлекательной перспективой, но поддерживает более быстрые записи, которые на самом деле не проверены. Вот почему так много шумихи вокруг O_DIRECT.

Я могу сказать, что у вас не установлен плагин InnoDB. С плагином InnoDB должно существовать несколько переменных.

Вы должны обновить InnoDB одним из двух способов:

Как только вы это сделаете, вы можете увеличить InnoDB до

  • доступ к более процессорам и ядрам
  • увеличить потоки ввода-вывода для чтения и записи
  • масштабировать емкость ввода /вывода (это особенно необходимо для разных носителей)

Вот мои прошлые сообщения о настройках, которые вы можете изменить для этого:

ответил RolandoMySQLDBA 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 13 Sep 2012 15:23:18 +0400 2012, 15:23:18
1

Мне всегда казалось, что O_DIRECT лучше для производительности, так как он предотвращает двойную буферизацию. Кроме того, если у вас есть аппаратный RAID с кешем записи с батареей. Конечно, это также зависит от рабочей нагрузки, будь вы READ или WRITE тяжелым.

Кроме того, вопрос для экспертов: выполните дополнительные вызовы fsync() для O_DIRECT вызывают заметное ухудшение общей производительности или это незначительно? Я еще не видел, что тесты показывают это.

Кроме того, обратите внимание, что Percona позволила установить innodb_flush_method=ALL_O_DIRECT, который обеспечивает прямой ввод-вывод не только в файлах данных InnoDB, но также и в журналах транзакций InnoDB.

ответил Derek Schultz 11 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 11 Sep 2012 06:07:52 +0400 2012, 06:07:52

Похожие вопросы

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

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132