W jednym z moich środowisk produkcyjnych mamy dwa wystąpienia działające w klastrze RedHat, z jednym wystąpieniem produkcyjnym powiązanym z klastrem.
Mamy pamięć główną 125G z pulą buforów InnoDB 24G zajmowaną przez instancję 1 i 12G zajmowaną przez instancję 2, która nie jest powiązana z klastrem RedHat. Zarówno dzienniki danych, jak i dzienników transakcji znajdują się na partycji dysku LVM z systemem plików ext3.
W celu zwiększenia wydajności i lepszej przepustowości we / wy zdecydowałem się innodb_flush_methodna O_DIRECT.
W odniesieniu do dokumentacji MySQL:
Gdzie danych InnoDB i pliki dziennika znajdują się w sieci SAN, stwierdzono, że ustawienie
innodb_flush_methodsięO_DIRECTmoże pogorszyć osiągi prostychSELECTwypowiedzi trzykrotnie.
Odnosząc się do wysokowydajnej wersji MySQL 2 i 3, stwierdzono, że programiści InnoDB znaleźli błędy w używaniu innodb_flush_method=O_DSYNC. O_SYNCi O_DSYNCsą podobne do fsync()i fdatasync(): O_SYNCsynchronizuje zarówno dane, jak i metadane, natomiast O_DSYNCsynchronizuje tylko dane.
Jeśli to wszystko wydaje się być wyjaśnieniem bez porady, oto rada:
jeśli używasz systemu operacyjnego typu Unix, a kontroler RAID ma pamięć podręczną na baterie, zalecamy użycie tej opcji
O_DIRECT. Jeśli nie, domyślnie lubO_DIRECTprawdopodobnie będzie najlepszym wyborem, w zależności od aplikacji.
Przez google otrzymałem ten raport porównawczy: na temat O_DSYNCvsO_DIRECT
Raport Bench Mark: =================== Kompleksowy test transakcyjny rzędu 1B, 64 wątków * SAN O_DIRECT: żądania odczytu / zapisu: 31560140 (8766,61 na sekundę) * SAN O_DSYNC: żądania odczytu / zapisu: 5179457 (1438,52 na sekundę) * SAN fdatasync: żądania odczytu / zapisu: 9445774 (2623.66 na sekundę) * Dysk lokalny O_DIRECT: żądania odczytu / zapisu: 3258595 (905,06 na sekundę) * Dysk lokalny O_DSYNC: żądania odczytu / zapisu: 3494632 (970.65 na sekundę) * Fdatasync na dysku lokalnym: żądania odczytu / zapisu: 4223757 (1173,04 na sekundę
Jednak O_DIRECTwyłącza pamięć podręczną poziomu OS, gdzie podwójne buforowanie może być wyłączona, które wykazują pewne lepsze I / O przepustowość.
Czy lepiej jest iść z O_DIRECT, niż O_DSYNC? Te dwie opcje są nieco mylące. Która opcja może wykazać lepszą przepustowość we / wy i zwiększenie wydajności bez żadnego wpływu na dane, odczyty / zapisy, szczególnie w środowisku produkcyjnym? Jakieś lepsze sugestie oparte na osobistych doświadczeniach?
Widziałem aktualizację Rolando w poście :
Nadal istnieje niewielkie zamieszanie dotyczące obu tych parametrów. Tam, gdzie mogłem zobaczyć większość szablonów konfiguracji produkcji
O_DIRECT, nie widziałem żadnego zalecającegoO_DSYNC.
System
- MySQL 5.1.51-enterprise-gpl-pro-log
- Red Hat Enterprise Linux Server wersja 5.5
- DELL DRAC z kontrolerem RAID z pamięcią podręczną zapisu 512 MB
- Kontrolery Dell PERC H700 z jednostką zasilania awaryjnego (BBU).
Dodatkowe informacje
mysql> pokaż zmienne takie jak 'innodb_thread_concurrency'; + --------------------------- + ------- + | Zmienna nazwa | Wartość | + --------------------------- + ------- + | innodb_thread_concurrency | 96 | + --------------------------- + ------- + 1 rząd w zestawie (0,00 s) mysql> pokaż zmienne takie jak 'innodb_read_io_threads'; Pusty zestaw (0,00 s) mysql> pokaż zmienne takie jak 'innodb_write_io_threads'; Pusty zestaw (0,00 s)
Używamy domyślnej wtyczki, więc zamieściłem informacje ze statusu InnoDB:
mysql> WYBIERZ * Z wtyczek GDZIE PLUGIN_NAME PODOBA „% innodb%” ORAZ PLUGIN_TYPE PODOBNY „SILNIK PRZECHOWYWANIA” \ G
*************************** 1. wiersz ********************** *******
PLUGIN_NAME: InnoDB
WERSJA PLUGIN: 1.0
PLUGIN_STATUS: AKTYWNY
PLUGIN_TYPE: SILNIK MAGAZYNOWY
PLUGIN_TYPE_VERSION: 50151,0
PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
PLUGIN_AUTHOR: Innobase OY
PLUGIN_DESCRIPTION: Obsługuje transakcje, blokowanie na poziomie wiersza i klucze obce
PLUGIN_LICENSE: GPL
1 rząd w zestawie (0,00 s)