Dostrajanie wydajności bazy danych dla MariaDB

Od czasu, gdy MySQL został pierwotnie rozwidlony w celu utworzenia MariaDB, był szeroko obsługiwany i szybko przyjmowany przez dużą grupę odbiorców w społeczności baz danych open source. Pierwotnie zamiennik typu drop-in, MariaDB zaczął odróżniać się od MySQL, zwłaszcza w wydaniu MariaDB 10.2.

Pomimo tego jednak nadal nie ma znaczącej różnicy między MariaDB i MySQL, ponieważ oba mają silniki, które są kompatybilne i mogą działać ze sobą natywnie. Nie zdziw się więc, jeśli dostrajanie konfiguracji MariaDB ma podobne podejście do dostrajania MySQL.

Ten blog omówi dostrajanie MariaDB, w szczególności systemów działających w środowisku Linux.

Optymalizacja sprzętu i systemu MariaDB

MariaDB zaleca ulepszenie sprzętu w następującej kolejności priorytetów...

Pamięć

Pamięć jest najważniejszym czynnikiem dla baz danych, ponieważ umożliwia dostosowanie zmiennych systemowych serwera. Więcej pamięci oznacza większe pamięci podręczne kluczy i tabel, które są przechowywane w pamięci, dzięki czemu dyski mają dostęp, o rząd wielkości wolniej, są następnie zmniejszane.

Pamiętaj jednak, że zwykłe dodanie większej ilości pamięci może nie przynieść drastycznych ulepszeń, jeśli zmienne serwera nie są ustawione tak, aby wykorzystywały dodatkową dostępną pamięć.

Korzystanie z większej liczby gniazd pamięci RAM na płycie głównej zwiększa częstotliwość magistrali i będzie większe opóźnienie między pamięcią RAM a procesorem. Oznacza to, że preferowane jest użycie największego rozmiaru pamięci RAM na gniazdo.

Dyski

Szybki dostęp do dysku ma kluczowe znaczenie, ponieważ ostatecznie to tam znajdują się dane. Kluczową wartością jest czas wyszukiwania dysku (miara tego, jak szybko dysk fizyczny może się poruszać, aby uzyskać dostęp do danych), więc wybieraj dyski o jak najkrótszym czasie wyszukiwania. Możesz także dodać dedykowane dyski dla plików tymczasowych i dzienników transakcji.

Szybki Ethernet

Przy odpowiednich wymaganiach dotyczących przepustowości Internetu, szybka sieć Ethernet oznacza, że może szybciej reagować na żądania klientów, czas odpowiedzi replikacji w celu odczytu dzienników binarnych na urządzeniach podrzędnych, szybsze czasy odpowiedzi są również bardzo ważne, szczególnie w przypadku Galera klastry oparte.

procesor

Chociaż wąskie gardła sprzętowe często występują gdzie indziej, szybsze procesory umożliwiają szybsze wykonywanie obliczeń i szybsze przesyłanie wyników do klienta. Oprócz szybkości procesora ważnymi czynnikami do rozważenia są również szybkość magistrali procesora i rozmiar pamięci podręcznej.

Ustawianie harmonogramu we/wy dysku

Programy planujące we/wy istnieją jako sposób na optymalizację żądań dostępu do dysku. Łączy żądania we/wy do podobnych lokalizacji na dysku. Oznacza to, że dysk nie musi tak często wyszukiwać i poprawia ogromny ogólny czas odpowiedzi oraz oszczędza operacje dyskowe. Zalecane wartości wydajności we/wy to noop i ostateczny termin.

noop przydaje się do sprawdzania, czy złożone decyzje innych planistów dotyczące planowania we/wy nie powodują regresji wydajności we/wy. W niektórych przypadkach może to być pomocne w przypadku urządzeń, które same planują operacje we/wy, takich jak inteligentna pamięć masowa, lub urządzeń, które nie są zależne od ruchu mechanicznego, takich jak dyski SSD. Zwykle harmonogram DEADLINE I/O jest lepszym wyborem dla tych urządzeń, ale ze względu na mniejsze obciążenie NOOP może generować lepszą wydajność w przypadku niektórych obciążeń.

W przypadku terminów jest to zorientowany na opóźnienia harmonogram we/wy. Każde żądanie I/O ma przypisany termin. Zazwyczaj żądania są przechowywane w kolejkach (odczyt i zapis) posortowanych według numerów sektorów. Algorytm DEADLINE utrzymuje dwie dodatkowe kolejki (odczyt i zapis), w których żądania są sortowane według terminu. Dopóki żadne żądanie nie przekroczy limitu czasu, używana jest kolejka „sektora”. W przypadku przekroczenia limitu czasu żądania z kolejki „deadline” są obsługiwane, dopóki nie będzie już żadnych wygasłych żądań. Ogólnie algorytm preferuje odczyty niż zapisy.

W przypadku urządzeń PCIe (dyski SSD NVMe) mają one własne duże kolejki wewnętrzne wraz z szybką obsługą i nie wymagają ani nie korzystają z ustawiania harmonogramu we/wy. Zaleca się, aby nie mieć jawnego parametru konfiguracyjnego trybu harmonogramu.

Możesz sprawdzić ustawienia harmonogramu za pomocą:

cat /sys/block/${DEVICE}/queue/scheduler

Na przykład powinno wyglądać tak:

cat /sys/block/sda/queue/scheduler

[noop] deadline cfq

Aby uczynić to na stałe, edytuj plik konfiguracyjny /etc/default/grub, poszukaj zmiennej GRUB_CMDLINE_LINUX i dodaj windę tak jak poniżej:

GRUB_CMDLINE_LINUX="elevator=noop"

Zwiększ limit otwartych plików

Aby zapewnić dobrą wydajność serwera, całkowita liczba połączeń klientów, plików baz danych i plików dziennika nie może przekraczać maksymalnego limitu deskryptorów plików w systemie operacyjnym (ulimit -n). Systemy Linux ograniczają liczbę deskryptorów plików, które może otworzyć dowolny proces, do 1024 na proces. Na aktywnych serwerach baz danych (zwłaszcza produkcyjnych) może łatwo osiągnąć domyślny limit systemowy.

Aby to zwiększyć, edytuj /etc/security/limits.conf i określ lub dodaj następujące:

mysql soft nofile 65535

mysql hard nofile 65535

To wymaga ponownego uruchomienia systemu. Następnie możesz potwierdzić, uruchamiając następujące polecenie:

$ ulimit -Sn

65535

$ ulimit -Hn

65535

Opcjonalnie możesz ustawić to poprzez mysqld_safe, jeśli uruchamiasz proces mysqld przez mysqld_safe,

[mysqld_safe]

open_files_limit=4294967295

lub jeśli używasz systemd,

sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF

[Service]



LimitNOFILE=infinity

EOF

sudo systemctl daemon-reload

Ustawianie zamiany w systemie Linux dla MariaDB

Linux Swap odgrywa dużą rolę w systemach baz danych. Działa jak koło zapasowe w pojeździe, gdy nieprzyjemne wycieki pamięci przeszkadzają w pracy, maszyna zwolni... ale w większości przypadków nadal będzie nadawała się do wykonania przydzielonego zadania.

Aby zastosować zmiany do swojej wymiany, po prostu uruchom,

sysctl -w vm.swappiness=1

Odbywa się to dynamicznie, bez konieczności ponownego uruchamiania serwera. Aby był trwały, edytuj /etc/sysctl.conf i dodaj linię,

vm.swappiness=1

Dosyć często ustawia się swappiness=0, ale od czasu wydania nowych jąder (tj. jądra> 2.6.32-303), wprowadzono zmiany, więc musisz ustawić vm.swappiness=1.

Optymalizacja systemu plików dla MariaDB

Najpopularniejsze systemy plików używane w środowiskach Linux z MariaDB to ext4 i XFS. Dostępne są również pewne konfiguracje do implementacji architektury przy użyciu ZFS i BRTFS (zgodnie z dokumentacją MariaDB).

Oprócz tego, większość konfiguracji baz danych nie wymaga rejestrowania czasu dostępu do pliku. Możesz chcieć to wyłączyć podczas montowania woluminu w systemie. Aby to zrobić, edytuj swój plik /etc/fstab. Na przykład na woluminie o nazwie /dev/md2 wygląda to tak:

/dev/md2 / ext4 defaults,noatime 0 0

Tworzenie optymalnej instancji MariaDB

Przechowuj dane w oddzielnym woluminie

Zawsze idealnie jest oddzielić dane bazy danych na osobnym woluminie. Ten wolumen jest przeznaczony specjalnie dla tych typów szybkich wolumenów pamięci masowej, takich jak karty SSD, NVMe lub PCIe. Na przykład, jeśli cały wolumin systemowy ulegnie awarii, wolumin bazy danych będzie bezpieczny i będziesz mieć pewność, że nie będzie to miało wpływu na awarię sprzętu pamięci masowej.

Dostosuj MariaDB, aby efektywnie wykorzystywać pamięć

innodb_buffer_pool_size

Podstawową wartością do dostosowania na serwerze bazy danych z całkowicie/głównie tabelami XtraDB/InnoDB może być ustawiona do 80% całkowitej pamięci w tych środowiskach. Jeśli jest ustawiony na 2 GB lub więcej, prawdopodobnie będziesz chciał również dostosować innodb_buffer_pool_instances. Możesz ustawić to dynamicznie, jeśli używasz MariaDB w wersji>=10.2.2. W przeciwnym razie wymaga ponownego uruchomienia serwera.

tmp_memory_table_size/max_heap_table_size

W przypadku tmp_memory_table_size (tmp_table_size), jeśli masz do czynienia z dużymi tabelami tymczasowymi, ustawienie tej wyższej wartości zapewnia wzrost wydajności, ponieważ będą one przechowywane w pamięci. Jest to powszechne w zapytaniach, które intensywnie używają GROUP BY, UNION lub podzapytań. Chociaż jeśli max_heap_table_size jest mniejszy, zastosowanie ma dolny limit. Jeśli tabela przekracza limit, MariaDB konwertuje ją na tabelę MyISAM lub Aria. Możesz sprawdzić, czy konieczne jest zwiększenie, porównując zmienne stanu Created_tmp_disk_tables i Created_tmp_tables, aby zobaczyć, ile tabel tymczasowych z łącznej liczby utworzonych wymaga przekonwertowania na dysk. Często złożone zapytania GROUP BY są odpowiedzialne za przekroczenie limitu.

Podczas gdy max_heap_table_size, jest to maksymalny rozmiar tabel MEMORY tworzonych przez użytkownika. Wartość ustawiona w tej zmiennej ma zastosowanie tylko do nowo utworzonych lub ponownie utworzonych tabel, a nie do istniejących. Mniejszy z wartości max_heap_table_size i tmp_table_size ogranicza również wewnętrzne tabele w pamięci. Gdy maksymalny rozmiar zostanie osiągnięty, wszelkie kolejne próby wstawienia danych spowodują wyświetlenie błędu „tabela ... jest pełna”. Tabele tymczasowe utworzone za pomocą polecenia CREATE TEMPORARY nie zostaną przekonwertowane do formatu Aria, jak ma to miejsce w przypadku wewnętrznych tabel tymczasowych, ale również otrzymają błąd dotyczący zapełnienia tabeli.

innodb_log_file_size

Duże pamięci z szybkim przetwarzaniem i szybkim dyskiem I/O nie są nowe i mają rozsądną cenę, zgodnie z zaleceniami. Jeśli wolisz większą wydajność, zwłaszcza podczas i podczas obsługi transakcji InnoDB, ustawienie zmiennej innodb_log_file_size na większą wartość, taką jak 5Gib lub nawet 10GiB, jest rozsądne. Zwiększenie oznacza, że większe transakcje mogą być uruchamiane bez konieczności wykonywania dyskowych operacji we/wy przed zatwierdzeniem.

join_buffer_size

W niektórych przypadkach w zapytaniach brakuje odpowiedniego indeksowania lub po prostu istnieją przypadki, w których to zapytanie jest potrzebne. Nie, chyba że będzie ona mocno wywoływana lub wywoływana z perspektywy klienta, ustawienie tej zmiennej jest najlepsze na poziomie sesji. Zwiększ ją, aby uzyskać szybsze pełne złączenia, gdy dodawanie indeksów nie jest możliwe, ale pamiętaj o problemach z pamięcią, ponieważ złączenia zawsze przydzielają minimalny rozmiar.

Ustaw swój max_allowed_packet

MariaDB ma taką samą naturę jak MySQL podczas obsługi pakietów. Dzieli dane na pakiety, a klient musi być świadomy wartości zmiennej max_allowed_packet. Serwer będzie miał bufor do przechowywania treści o maksymalnym rozmiarze odpowiadającym tej wartości max_allowed_packet. Jeśli klient wyśle więcej danych niż max_allowed_packet rozmiar, gniazdo zostanie zamknięte. Dyrektywa max_allowed_packet określa maksymalny rozmiar pakietu, który można wysłać.

Ustawienie tej wartości zbyt nisko może spowodować zatrzymanie zapytania i zamknięcie połączenia klienta, co jest dość powszechne w przypadku otrzymywania błędów, takich jak ER_NET_PACKET_TOO_LARGE lub Utracone połączenie z serwerem MySQL podczas zapytania. Idealnie, zwłaszcza w przypadku większości dzisiejszych wymagań aplikacji, możesz zacząć ustawiać to na 512MiB. Jeśli jest to aplikacja o niskim zapotrzebowaniu, po prostu użyj wartości domyślnej i ustaw tę zmienną tylko za pośrednictwem sesji w razie potrzeby, jeśli dane do wysłania lub odebrania są zbyt duże niż wartość domyślna (16 MiB od wersji MariaDB 10.2.4). W przypadku niektórych obciążeń, które wymagają przetworzenia dużych pakietów, należy dostosować ich wyższą wartość zgodnie z własnymi potrzebami, zwłaszcza w przypadku replikacji. Jeśli parametr max_allowed_packet jest zbyt mały na urządzeniu podrzędnym, powoduje to również zatrzymanie wątku we/wy przez urządzenie podrzędne.

Korzystanie z puli wątków

W niektórych przypadkach to dostrojenie może nie być dla Ciebie konieczne lub zalecane. Pule wątków są najbardziej wydajne w sytuacjach, w których zapytania są stosunkowo krótkie, a obciążenie jest powiązane z procesorem (obciążenia OLTP). Jeśli obciążenie nie jest powiązane z procesorem, możesz nadal chcieć ograniczyć liczbę wątków w celu zapisania pamięci dla buforów pamięci bazy danych.

Korzystanie z puli wątków jest idealnym rozwiązaniem, zwłaszcza jeśli w Twoim systemie występuje przełączanie kontekstu, a Ty znajdujesz sposoby na zmniejszenie tego i utrzymanie mniejszej liczby wątków niż liczba klientów. Jednak ta liczba również nie powinna być zbyt niska, ponieważ również chcemy maksymalnie wykorzystać dostępne procesory. Dlatego w idealnym przypadku powinien istnieć jeden aktywny wątek dla każdego procesora na komputerze.

Możesz ustawić thread_pool_max_threads, thread_pool_min_threads dla maksymalnej i minimalnej liczby wątków. W przeciwieństwie do MySQL jest to dostępne tylko w MariaDB.

Ustaw zmienną thread_handling, która określa, jak serwer obsługuje wątki dla połączeń klientów. Oprócz wątków dla połączeń klientów dotyczy to również niektórych wewnętrznych wątków serwera, takich jak wątki podrzędne Galera.

Dostosuj pamięć podręczną tabeli + max_connections

Jeśli napotykasz sporadyczne zdarzenia na liście procesów dotyczące stanów otwierania tabel i zamykania tabel, może to oznaczać, że musisz zwiększyć pamięć podręczną tabel. Możesz to również monitorować za pomocą wiersza poleceń mysql, uruchamiając SHOW GLOBAL STATUS LIKE 'Open%table%'; i monitoruj zmienne stanu.

Dla max_connections, jeśli aplikacja wymaga wielu jednoczesnych połączeń, możesz ustawić to na 500.

Dla table_open_cache będzie to całkowita liczba twoich tabel, ale najlepiej jest dodać więcej w zależności od typu zapytań, które obsługujesz, ponieważ tymczasowe tabele również będą buforowane. Na przykład, jeśli masz 500 stołów, rozsądnie byłoby zacząć od 1500.

Podczas gdy twoje table_open_cache_instances zacznij ustawiać go na 8. Może to poprawić skalowalność poprzez zmniejszenie rywalizacji między sesjami, pamięć podręczną otwartych tabel można podzielić na kilka mniejszych instancji pamięci podręcznej o rozmiarze table_open_cache / table_open_cache_instances.

W przypadku InnoDB table_definition_cache działa jako miękki limit liczby instancji otwartych tabel w pamięci podręcznej słownika danych InnoDB. Wartość do zdefiniowania określi liczbę definicji tabel, które mogą być przechowywane w pamięci podręcznej definicji. Jeśli używasz dużej liczby tabel, możesz utworzyć dużą pamięć podręczną definicji tabeli, aby przyspieszyć otwieranie tabel. Pamięć podręczna definicji tabeli zajmuje mniej miejsca i nie używa deskryptorów plików, w przeciwieństwie do normalnej pamięci podręcznej tabel. Minimalna wartość to 400. Wartość domyślna jest oparta na następującym wzorze z ograniczeniem do 2000:

MIN(400 + table_open_cache / 2, 2000)

Jeżeli liczba otwartych instancji tabel przekroczy ustawienie table_definition_cache, mechanizm LRU zaczyna oznaczać instancje tabel do eksmisji i ostatecznie usuwa je z pamięci podręcznej słownika danych. Limit pomaga rozwiązać sytuacje, w których znaczne ilości pamięci byłyby używane do buforowania rzadko używanych instancji tabel do następnego ponownego uruchomienia serwera. Liczba instancji tabeli z buforowanymi metadanymi może być wyższa niż limit zdefiniowany przez table_definition_cache, ponieważ instancje tabel nadrzędnych i podrzędnych z relacjami kluczy obcych nie są umieszczane na liście LRU i nie podlegają wykluczeniu z pamięci.

W przeciwieństwie do table_open_cache, table_definition_cache nie używa deskryptorów plików i jest znacznie mniejszy.

Obsługa pamięci podręcznej zapytań

Najlepiej zalecamy wyłączenie pamięci podręcznej zapytań we wszystkich ustawieniach MariaDB. Musisz upewnić się, że query_cache_type=OFF i query_cache_size=0, aby całkowicie wyłączyć pamięć podręczną zapytań. W przeciwieństwie do MySQL, MariaDB nadal w pełni obsługuje pamięć podręczną zapytań i nie planuje wycofania jej obsługi pamięci podręcznej zapytań. Niektórzy twierdzą, że pamięć podręczna zapytań nadal zapewnia im korzyści w zakresie wydajności. Jednak ten post z Percona The MySQL query cache:Najgorszy wróg lub najlepszy przyjaciel ujawnia, że pamięć podręczna zapytań, jeśli jest włączona, powoduje obciążenie i pokazuje, że ma słabą wydajność serwera.

Jeśli zamierzasz używać pamięci podręcznej zapytań, upewnij się, że monitorujesz pamięć podręczną zapytań, uruchamiając SHOW GLOBAL STATUS LIKE 'Qcache%';. Qcache_inserts zawiera liczbę zapytań dodanych do pamięci podręcznej zapytań, Qcache_hits zawiera liczbę zapytań, które wykorzystały pamięć podręczną zapytań, a Qcache_lowmem_prunes zawiera liczbę zapytań, które zostały usunięte z pamięci podręcznej z powodu braku pamięci. W odpowiednim czasie używanie i włączanie pamięci podręcznej zapytań może ulec fragmentacji. Wysoka wartość Qcache_free_blocks względem Qcache_total_blocks może wskazywać na fragmentację. Aby go zdefragmentować, uruchom FLUSH QUERY CACHE. Spowoduje to defragmentację pamięci podręcznej zapytań bez porzucania jakichkolwiek zapytań.

Zawsze monitoruj swoje serwery

Bardzo ważne jest prawidłowe monitorowanie węzłów MariaDB. Dostępne są popularne narzędzia do monitorowania (takie jak Nagios, Zabbix lub PMM), jeśli wolisz narzędzia darmowe i o otwartym kodzie źródłowym. W przypadku korporacyjnych i w pełni wyposażonych narzędzi sugerujemy wypróbowanie ClusterControl, ponieważ zapewnia on nie tylko monitorowanie, ale także oferuje doradców wydajności, alerty i alarmy, które pomagają poprawić wydajność systemu i być na bieżąco z aktualnymi trendy podczas współpracy z zespołem pomocy technicznej. Monitorowanie bazy danych za pomocą ClusterControl jest bezpłatne i stanowi część wersji Community.

Wnioski

Dostrajanie konfiguracji MariaDB to prawie to samo podejście, co MySQL, ale z pewnymi rozbieżnościami, ponieważ różni się niektórymi podejściami i wersjami, które obsługuje. MariaDB jest teraz inną jednostką w świecie baz danych i szybko zyskała zaufanie społeczności bez żadnego FUD. Mają swoje własne powody, dla których należy to zaimplementować w ten sposób, więc bardzo ważne jest, abyśmy wiedzieli, jak to dostroić i zoptymalizować serwery MariaDB.