В одному з моїх виробничих середовищ у нас є два екземпляри, що працюють на кластері RedHat, причому один виробничий екземпляр пов'язаний з кластером.
У нас є 125G основна пам'ять з 24G InnoDB буферним пулом, зайнятим instance1 та 12G, зайнятими instance2, яка не пов'язана з кластером RedHat. І журнали даних, і журнали транзакцій розташовані на дисковому розділі LVM з файловою системою ext3.
Для підвищення продуктивності і краще I / O пропускної здатності я вирішив змінити 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, мабуть, буде найкращим вибором, залежно від вашої програми.
За допомогою googling я отримав цей звіт про O_DSYNCпорівняння : on vsO_DIRECT
Звіт про порівняльну оцінку: ==================== Комплексний транзакційний тест 1B рядків, 64 теми * SAN O_DIRECT: запити для читання / запису: 31560140 (8766,61 за секунду) * SAN O_DSYNC: запити на читання / запис: 5179457 (1438,52 в секунду) * SAN fdatasync: запити для читання / запису: 9445774 (2623,66 за секунду) * Локальний диск O_DIRECT: запити на читання / запис: 3258595 (905.06 в секунду) * Локальний диск O_DSYNC: запити на читання / запис: 3494632 (970,65 в секунду) * Fdatasync локального диска: запити на читання / запис: 4223757 (1173,04 за секунду)
Однак O_DIRECTвимикає кеш рівня ОС, де може бути відключено подвійне кешування, що показує кращу пропускну здатність вводу / виводу.
Чи добре їхати, O_DIRECTа не O_DSYNC? Ці два варіанти трохи заплутані. Який варіант може виявити кращу пропускну здатність вводу / виводу та підвищення продуктивності, не впливаючи на дані, читає / записує особливо у виробництві? Якісь кращі пропозиції, засновані на вашому особистому досвіді?
Я міг побачити оновлення Rolando у публікації :
І все-таки існує незначна плутанина обох цих параметрів. Де я міг бачити більшість шаблонів конфігурації виробництва, використовуючи
O_DIRECT, я не бачив, де рекомендувавO_DSYNC.
Система
- 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'; + --------------------------- + ------- + | Ім'я змінної | Значення | + --------------------------- + ------- + | innodb_thread_concurrency | 96 | + --------------------------- + ------- + 1 ряд у наборі (0,00 сек) mysql> показує змінні типу 'innodb_read_io_threads'; Порожній набір (0,00 сек) mysql> показує змінні типу 'innodb_write_io_threads'; Порожній набір (0,00 сек)
Ми використовуємо плагін за замовчуванням, тому я опублікував інформацію зі статусу InnoDB:
mysql> SELECT * ІЗ плагінів, де PLUGIN_NAME НЕОБХОДИМО '% innodb%' І PLUGIN_TYPE ПОДОБИТЬ 'ДВИГАТИХ ЗБЕРІГАННЯ' \ G
*************************** 1. рядок ******************** *******
PLUGIN_NAME: InnoDB
ПЛУГІН_ВЕРСІЯ: 1.0
ПЛУГІН_СТАТУС: АКТИВНІ
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 сек)