innodb_flush_method = O_DIRECT vs O_DSYNC wpływ na wydajność na ext3 z partycją dysku LVM

12

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 prostych SELECTwypowiedzi 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 lub O_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ącego O_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)
mysql performance innodb mysql-5.1 redhat Gopinath
źródło
Powiązane: Wyjaśnienie na temat zmiennej MySQL innodb_flush_method
Gopinath

Odpowiedzi:

7

21 stycznia 2009 r. Peter Zaitsev stwierdził na mysqlperformanceblog.com, co następuje

Jako wezwanie do działania - z pewnością chciałbym, aby ktoś sprawdził, czy EXT3 można naprawić w tym względzie, ponieważ jest to zdecydowanie najpopularniejszy system plików w systemie Linux. Warto również sprawdzić, czy coś można zrobić po stronie MySQL - może otwierać binlog z O_DSYNCflagą, jeśli sync_binlog=1zamiast fsync pomoże? Lub może być wstępne przydzielenie binlog byłoby dobrym rozwiązaniem.

Jak dotąd nie wiem, by nikt nie dotknął tego problemu. O_DSYNCdomyślnie nie jest atrakcyjną perspektywą, ale obsługuje szybsze zapisy, które nie są tak naprawdę weryfikowane. Dlatego wokół jest tyle szumu O_DIRECT.

Mogę powiedzieć, że nie masz zainstalowanej wtyczki InnoDB. Dzięki wtyczce InnoDB powinno istnieć kilka zmiennych.

Powinieneś zaktualizować InnoDB na jeden z dwóch sposobów:

Gdy to zrobisz, możesz ulepszyć InnoDB do

  • dostęp do większej liczby procesorów i rdzeni
  • zwiększyć liczbę wątków we / wy odczytu i zapisu
  • skalować pojemność I / O (jest to szczególnie potrzebne w przypadku różnych nośników pamięci)

Oto moje poprzednie posty na temat ustawień, które możesz zmienić w tym celu:

RolandoMySQLDBA
źródło
1

Zawsze miałem wrażenie, że O_DIRECTjest lepsza pod względem wydajności, ponieważ zapobiega podwójnemu buforowaniu. Ponadto, pod warunkiem, że masz sprzętową macierz RAID z pamięcią podręczną zapisu zasilaną bateryjnie. Oczywiście zależy to również od obciążenia pracą, niezależnie od tego, czy jesteś ciężko CZYTAĆ, czy PISAĆ.

Również pytanie do ekspertów: czy dodatkowych połączeń, aby fsync()za O_DIRECTprzyczynę zauważalne pogorszenie ogólnej wydajności, czy jest to nieistotne? Muszę jeszcze zobaczyć, jak to pokazują testy porównawcze.

Należy również pamiętać, że Percona umożliwiła ustawienie innodb_flush_method=ALL_O_DIRECT, które zapewnia bezpośrednie we / wy nie tylko w plikach danych InnoDB, ale także w dziennikach transakcji InnoDB w tym samym czasie.

Derek Schultz
źródło
2
W 2012 roku pula buforów nie skalowała się dobrze dla ogromnej pamięci RAM, więc wspomniane podwójne buforowanie może być dobre w przypadkach, gdy pamięć podręczna systemu operacyjnego jest znacznie większa niż pula buforów innodb. Jeśli chodzi o 5.6 i wyżej - mówię, że twoja odpowiedź jest w pełni poprawna.
noonex