it-swarm-eu.dev

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) 
12
Gopinath

Zpět 21. ledna 2009 Peter Zaitsev uvedl na mysqlperformanceblog.com

Jako výzva k akci - určitě bych chtěl, aby někdo zjistil, zda lze EXT3 v tomto ohledu opravit, protože se jedná o zdaleka nejběžnější systém souborů pro Linux. Rovněž stojí za to prozkoumat, zda lze něco udělat na straně MySQL - může být otevření binlogu s příznakem O_DSYNC, Pokud sync_binlog=1 Namísto použití fsync pomůže? Nebo by mohlo být dobrým řešením předběžná alokace binlogu.

Zatím vím, že se nikdo tento problém nedotkl. O_DSYNC Ve výchozím nastavení není lákavou vyhlídkou, ale přizpůsobí rychlejší zápisy, které nejsou skutečně ověřeny. Proto je kolem O_DIRECT Tolik humbuk.

Mohu říct, že nemáte nainstalovaný modul InnoDB. S pluginem InnoDB by mělo existovat několik proměnných.

InnoDB byste měli upgradovat jedním ze dvou způsobů:

Jakmile tak učiníte, můžete InnoDB vylepšit na

  • přístup k více procesorům a jádru
  • zvýšit čtení a zápis I/O vláken
  • přizpůsobit kapacitu I/O (to je zvláště nutné pro různá paměťová média)

Zde jsou mé minulé příspěvky týkající se nastavení, která můžete za tímto účelem změnit:

7
RolandoMySQLDBA

Vždy jsem měl dojem, že O_DIRECT Je lepší pro výkon, protože zabraňuje dvojímu ukládání do vyrovnávací paměti. Za předpokladu, že máte hardwarové pole RAID s mezipamětí pro zápis na baterie. Samozřejmě to také záleží na pracovní zátěži, ať už jste PŘEČTĚNÁ nebo PÍSEMNÁ.

Také zeptejte se odborníků: způsobují zvláštní volání funkce fsync() pro O_DIRECT Znatelné zhoršení celkového výkonu, nebo je to zanedbatelné? Ještě musím vidět, jak to ukazují měřítka.

Také si všimněte, že Percona povolila možnost nastavení innodb_flush_method=ALL_O_DIRECT, Která poskytuje přímé I/O nejen na datových souborech InnoDB, ale také na protokolech transakcí InnoDB současně.

1
Derek Schultz