innodb_flush_method = O_DIRECT против влияния производительности O_DSYNC на ext3 с разделом диска LVM


12

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

У нас есть 125G основной памяти с 24G буферным пулом InnoDB, занятым instance1 и 12G, занятым instance2, который не связан с кластером RedHat. Как данные, так и журналы транзакций находятся в дисковом разделе LVM с файловой системой ext3.

Для повышения производительности и повышения пропускной способности ввода / вывода я решил перейти innodb_flush_methodна O_DIRECT.

Со ссылкой на документацию MySQL:

Если данные InnoDB и лог файлы находятся на SAN, было установлено , что установка innodb_flush_methodв O_DIRECTможет привести к снижению производительности простых SELECTзаявлений в три раза.

Ссылаясь на высокопроизводительные MySQL Ver 2 и 3, он заявил, что разработчики InnoDB обнаружили ошибки при использовании innodb_flush_method=O_DSYNC. O_SYNCи O_DSYNCаналогичны fsync()и fdatasync(): O_SYNCсинхронизирует как данные, так и метаданные, тогда как O_DSYNCсинхронизирует только данные.

Если все это кажется большим объяснением без совета, вот совет:

Если вы используете Unix-подобную операционную систему и ваш RAID-контроллер имеет кэш-память с резервным питанием от батареи, мы рекомендуем вам использовать O_DIRECT. Если нет, то по умолчанию или O_DIRECT, вероятно, будет лучшим выбором, в зависимости от вашего приложения.

Погуглив, я получил этот отчет о тестах: по O_DSYNCсравнению сO_DIRECT

Отчет по стендовой оценке:
===================
Комплексный транзакционный тест 1B, 64 потока

 * SAN O_DIRECT: запросы на чтение / запись: 31560140 (8766,61 в секунду)
 * SAN O_DSYNC: запросы на чтение / запись: 5179457 (1438,52 в секунду)
 * SAN fdatasync: запросы на чтение / запись: 9445774 (2623,66 в секунду).
 * Local-disk O_DIRECT: запросы на чтение / запись: 3258595 (905,06 в секунду)
 * Local-disk O_DSYNC: запросы на чтение / запись: 3494632 (970,65 в секунду)
 * Локальный диск fdatasync: запросы на чтение / запись: 4223757 (1173,04 в секунду.

Однако O_DIRECTотключает кеш на уровне ОС, где можно отключить двойное кеширование, что показывает лучшую пропускную способность ввода-вывода.

Это хорошо, чтобы пойти с O_DIRECTчем O_DSYNC? Эти два варианта немного сбивают с толку. Какая опция может показать лучшую пропускную способность ввода-вывода и повышение производительности без какого-либо влияния на данные, особенно для чтения / записи, особенно на производстве? Есть лучшие предложения, основанные на вашем личном опыте?

Я мог видеть Обновление Роландо в посте :

Тем не менее, существует небольшая путаница по обоим этим параметрам. Где я мог видеть большинство используемых шаблонов конфигурации O_DIRECT, я не видел ни одного, где бы рекомендовал O_DSYNC.

система

  • MySQL 5.1.51-enterprise-gpl-pro-log
  • Red Hat Enterprise Linux Server, выпуск 5.5
  • DELL DRAC с Raid Controller, имеющим кэш обратной записи батареи 512MB
  • Контроллеры Dell PERC H700 с резервным аккумулятором (BBU).

Дополнительная информация

mysql> показать переменные типа 'innodb_thread_concurrency'; 

+ --------------------------- + ------- +
| Переменное_имя | Значение |
+ --------------------------- + ------- + 
| 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, ГДЕ PLUGIN_NAME НРАВИТСЯ '% innodb%' И PLUGIN_TYPE НРАВИТСЯ 'ДВИГАТЕЛЬ ХРАНИЛИЩА' \ 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 сек)

Ответы:


7

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

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

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

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

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

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

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

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


1

У меня всегда было впечатление, что O_DIRECTэто лучше для производительности, так как предотвращает двойную буферизацию. Кроме того, при условии, что у вас есть аппаратный RAID с резервным питанием от батареи. Конечно, это также зависит от рабочей нагрузки, будь то ЧИТАЙТЕ или НАПИШИТЕ много.

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

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


2
Еще в 2012 году пул буферов плохо масштабировался для огромной оперативной памяти, поэтому упомянутая двойная буферизация может быть полезна в случаях, когда кэш ОС намного больше, чем пул буферов innodb. Что касается 5.6 и выше - я говорю, что ваш ответ полностью действителен.
noonex,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.