innodb_flush_method = O_DIRECT vs. výkon O_DSYNC na ext3 s diskovým oddílem LVM

V jednom z mých produkčních prostředí jsou v klastru RedHat spuštěny dvě instance, přičemž jedna klastr výroby je spojen s klastrem.

Máme 125G hlavní paměti s 24G InnoDB vyrovnávací pamětí obsazenou instance1 a 12G obsazenou instance2, která není spojena s klastrem RedHat. Protokoly dat i transakcí jsou umístěny na diskové oblasti LVM se systémem souborů ext3.

Pro zvýšení výkonu a lepší propustnost I/O jsem se rozhodl změnit innodb_flush_method Na O_DIRECT.

S odkazem na dokumentaci MySQL:

Tam, kde jsou data a protokolové soubory InnoDB umístěny na SAN, bylo zjištěno, že nastavení innodb_flush_method Na O_DIRECT Může snížit výkon jednoduchých příkazů SELECT třikrát.

Pokud jde o vysoce výkonný MySQL Ver 2 a 3, uvedl, že vývojáři InnoDB našli chyby s použitím innodb_flush_method=O_DSYNC. O_SYNC A O_DSYNC Jsou podobné fsync() a fdatasync(): O_SYNC Synchronizuje data i metadata, zatímco O_DSYNC synchronizuje pouze data.

Pokud se to všechno zdálo jako vysvětlení bez rady, tady je rada:

pokud používáte operační systém podobný Unixu a váš řadič RAID má záložní baterii zálohovanou na baterie, doporučujeme použít O_DIRECT. Pokud ne, bude v závislosti na vaší aplikaci pravděpodobně nejlepší volbou výchozí nebo O_DIRECT.

Díky googlingu jsem dostal toto referenční zpráva: na O_DSYNC Vs O_DIRECT

 Zpráva o zkušebním stavu: 
 =================== 
 1B Řádkový komplexní transakční test, 64 vláken 
 
 * SAN O_DIRECT: požadavky na čtení a zápis: 31560140 (8766,61 za sekundu) 
 * SAN O_DSYNC: přečteno/požadavky na zápis: 5179457 (1438,52 za ​​sekundu) 
 * SAN fdatasync: požadavky na čtení/zápis: 9445774 (2623,66 za sekundu) 
 * Místní disk O_DIRECT: požadavky na čtení/zápis: 3258595 (905,06 za sekundu) 
 * Local-disk O_DSYNC: požadavky na čtení/zápis: 3494632 (970,65 za sekundu) 
 * Local-disk fdatasync: read/požadavky na zápis: 4223757 (1173,04 za sekundu 

O_DIRECT Však zakáže mezipaměť na úrovni OS, kde lze zakázat dvojité ukládání do mezipaměti, což ukazuje lepší propustnost I/O.

Je dobré jít raději s O_DIRECT Než s O_DSYNC? Tyto dvě možnosti jsou trochu matoucí. Která možnost může ukázat lepší propustnost I/O a zlepšení výkonu, aniž by to mělo dopad na data, čte/zapisuje zejména ve výrobě? Nějaké lepší návrhy na základě vaší osobní zkušenosti?

Viděl jsem Rolando Update v post :

Stále existuje mírný zmatek u obou těchto parametrů. Kde jsem viděl většinu konfiguračních šablon výroby pomocí O_DIRECT, Neviděl jsem žádné, kde doporučuji O_DSYNC.

Systém

• MySQL 5.1.51-enterprise-gpl-pro-log
• Vydání Red Hat Enterprise Linux Server 5.5
• Dell DRAC s ovladačem Raid s vyrovnávací pamětí pro zálohování baterií 512 MB
• Řadiče Dell PERC H700 se záložní baterií (BBU).

Dodatečné informace

 mysql> ukazují proměnné jako 'innodb_thread_concurrency'; 
 
 + --------------------------- + ------- + 
 | Název proměnné | Hodnota | 
 + --------------------------- + ------- + 
 | innodb_thread_concurrency | 96 | 
 + --------------------------- + ------- + 
 1 řádek v set (0.00 sec) 
 
 mysql> zobrazit proměnné jako 'innodb_read_io_threads'; 
 Prázdná sada (0,00 s) 
 
 Mysql> ukazují proměnné jako 'innodb_write_io_threads'; 
 Prázdná sada (0,00 s) 

Používáme výchozí plugin, takže jsem zveřejnil informace ze stavu InnoDB:

 mysql> VYBRAJTE * Z Pluginů, KDE PLUGIN_NAME LIKE '% innodb%' A PLUGIN_TYPE LIKE 'SKLADOVACÍ MOTOR'\G 
 ****************** *********** 1. řádek **************************** 
 PLUGIN_NAME: InnoDB 
 PLUGIN_VERSION: 1.0 
 PLUGIN_STATUS: AKTIVNÍ 
 PLUGIN_TYPE: SKLADOVACÍ MOTOR 
 PLUGIN_TYPE_VERSION: 50151.0 
 PLUGIN_LIBRARY: NULL [.____] PLUGLL_IB_____ .] PLUGIN_AUTHOR: Innobase OY 
 PLUGIN_DESCRIPTION: Podporuje transakce, zamykání na úrovni řádku a cizí klíče 
 PLUGIN_LICENSE: GPL 
 1 řádek v sadě (0,00 s)