Strojenie NVMe na serwerach Linux: kompletny przewodnik optymalizacji

Jeśli pracujesz z serwerami Linux i przeszedłeś na dyski NVMe, prawdopodobnie zauważyłeś, że chociaż są one znacznie szybsze niż dyski twarde, a nawet SSD SATANie zawsze widać spektakularne wyniki obiecywane w specyfikacjach w wersji produkcyjnej. Nie chodzi o to, że zawiódł Cię sprzęt: zazwyczaj powstrzymuje Cię system operacyjny, konfiguracja jądra i usługi.

W tym artykule pokażemy, jak wykonać poważne dostrajanie NVMe na serwerach LinuxUwzględnimy zarówno czystą wydajność (opóźnienie, IOPS i przepustowość), jak i trwałość dysku. Ponadto zintegrujemy ją z warstwą bazy danych (MySQL/MariaDB, zwłaszcza InnoDB) oraz z najlepszymi praktykami w zakresie wykorzystania dysków SSD i NVMe, aby zapewnić optymalną wydajność platformy. Celem jest płynne przejście od testów laboratoryjnych z Fio do rzeczywistych obciążeń produkcyjnych, które naprawdę zapierają dech w piersiach.

Wymagania wstępne i narzędzia do optymalizacji NVMe w systemie Linux

Przed rozpoczęciem zmiany parametrów konieczne jest posiadanie na korzeń do serwera i dobry plan kopii zapasowychWiele ustawień, które omówimy, ma wpływ na jądro, partycjonowanie, a nawet format urządzenia, więc jakikolwiek błąd może spowodować awarię usługi lub uniemożliwić odzyskanie woluminu.

Musisz też mieć określone narzędzia do zarządzania NVMe, monitorowania wejścia/wyjścia i przeprowadzania testów porównawczychW systemach Debian i Ubuntu możesz je zainstalować za pomocą:

Instalacja na Debianie/Ubuntu: sudo apt update
sudo apt install nvme-cli fio util-linux iotop sysstat numactl -y

W systemach bazujących na RHEL (Rocky, Alma, CentOS itp.) osiąga się je poprzez:

Instalacja w RHEL i pochodnych: sudo dnf update -y
sudo dnf install nvme-cli fio util-linux iotop sysstat numactl -y

Dzięki tym narzędziom będziesz mógł zidentyfikuj swoje urządzenia NVMe, sprawdź ich stan i aktualizacja oprogramowania układowego w systemie Linux, zmierz opóźnienie i przepustowość obiektywnie i powtarzalnie, coś krytycznego zanim się czegokolwiek dotknie, aby móc porównać „przed” i „po”.

Odkryj, zidentyfikuj i zmierz swoje urządzenia NVMe

Pierwszym krokiem jest wypisanie posiadanych przez Ciebie dysków NVMe i ich specyfikacji. Można to bardzo wyraźnie zobaczyć za pomocą nvme-cli i bez konieczności zmagania się z dziwnymi nazwami w /dev.

Wyświetl listę urządzeń NVMe: nvme list

Jeśli chcesz wejść głębiej, poniższe polecenie pokazuje Możliwości kontrolera NVMe (kolejki polecenia, maksymalny rozmiar transferu itp.):

Szczegóły kontrolera NVMe: nvme id-ctrl -H /dev/nvme0

Aby zobaczyć informacje na temat „przestrzeni nazw” (formaty LBA, rozmiary sektorów i względny ranking wydajności):

Szczegóły przestrzeni nazw NVMe: nvme id-ns -H /dev/nvme0n1

Zanim zaczniesz dostrajać system, warto zapisać Linia bazowa wydajności z fioMożna na przykład zmierzyć opóźnienie w losowych odczytach 4K za pomocą bezpośredniego wejścia/wyjścia:

Test bazowy (fio randread 4K): fio --name=randread --filename=/dev/nvme0n1 --rw=randread --bs=4k \
--iodepth=64 --numjobs=1 --ioengine=io_uring --direct=1 --time_based=1 --runtime=20

A sekwencyjna przepustowość odczytu przy 128K:

Test bazowy (fio seqread 128K): fio --name=seqread --filename=/dev/nvme0n1 --rw=read --bs=128k \
--iodepth=64 --numjobs=1 --ioengine=io_uring --direct=1 --time_based=1 --runtime=20

Aby zrozumieć, jak zachowuje się cały system, pomocne jest uzupełnienie tego o iostat i smart-log:

kontrole iostat / smart-log: iostat -x 2 10
nvme smart-log /dev/nvme0

W ten sposób będziesz wiedział, czy masz wąskie gardło czas obsługi kolejki, temperatura, błędy nośników lub po prostu w najwyższej warstwie (system plików, baza danych, itp.).

NVMe Power Management (APST) dla niskich opóźnień

Napędy NVMe wdrażają APST (Autonomiczne Przejście Stanu Zasilania)mechanizm oszczędzania energii poprzez wchodzenie w głębsze stany niskiego poboru mocy. To w porządku dla laptopyJednak na serwerze, w którym liczą się kolejki milisekundowe lub mikrosekundowe, takie „wybudzanie się” dysków SSD może powodować nieprzyjemne skoki opóźnień.

Jeśli masz priorytet stałe opóźnienie w oszczędzaniu energiiMożesz wyłączyć APST, dostosowując parametr modułu nvme_core (zobacz wiadomości o jądrze). W systemach z GRUB-em wystarczy dodać:

Wyłącz APST (GRUB): sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="nvme_core.default_ps_max_latency_us=0 /' /etc/default/grub
sudo update-grub

Po ponownym uruchomieniu jądro przestanie wprowadzać dysk w stan głębokiego oszczędzania energii i ogólnie rzecz biorąc, Kolejki opóźnień 99% i 99.9% powinny ulec poprawiepod warunkiem, że chłodzenie serwera jest odpowiednie do wzrostu temperatury.

Harmonogram wejścia/wyjścia odpowiedni dla ustawień NVMe i warstwy blokowej

Harmonogram wejścia/wyjścia to warstwa, która decyduje W jakiej kolejności obsługiwane są żądania odczytu i zapisu? w kierunku urządzenia. W przypadku napędów mechanicznych sensowne było stosowanie złożonych harmonogramów optymalizujących fizyczny ruch głowic, ale w przypadku NVMe jest to zbędne, a nawet może być przeszkodą.

W większości nowoczesnych dystrybucji dyski NVMe już korzystają harmonogram „brak” (lub mq-deadline w niektórych przypadkach)Mimo wszystko warto to sprawdzić:

Sprawdź harmonogram wejścia/wyjścia: cat /sys/block/nvme0n1/queue/scheduler

Jeśli widzisz coś innego, a Twoje obciążenie to przede wszystkim losowe operacje wejścia/wyjścia o niskim opóźnieniu, możesz wymusić na harmonogramie ustawienie „brak”:

Wymuś harmonogram 'brak': echo none | sudo tee /sys/block/nvme0n1/queue/scheduler

W przypadku obciążeń o dużej mieszanym charakterze i intensywnych operacjach zapisu „mq-deadline” może zapewnić lepsza równowaga między przepustowością a opóźnieniem:

Wymuś harmonogram „mq-deadline”: echo mq-deadline | sudo tee /sys/block/nvme0n1/queue/scheduler

Oprócz harmonogramu warstwa bloków oferuje dwie inne ważne kontrole: odczyt z wyprzedzeniem i maksymalny rozmiar żądaniaMetoda odczytu z wyprzedzeniem (read_ahead_kb) „odczytuje z wyprzedzeniem” więcej danych, niż zostało zażądane, co jest przydatne w przypadku długich sekwencyjnych dostępów, ale nieefektywne w przypadku dostępu losowego.

Typowe wartości read_ahead_kb: echo 128 | sudo tee /sys/block/nvme0n1/queue/read_ahead_kb # cargas aleatorias (BBDD)
echo 4096 | sudo tee /sys/block/nvme0n1/queue/read_ahead_kb # secuencial grande (backups, vídeo, etc.)

Z szacunkiem do maksymalny rozmiar żądania (max_sectors_kb)Zaleca się, aby dostosować ją do optymalnego rozmiaru wejścia/wyjścia jednostki i nie przekraczać maksymalnego dopuszczalnego sprzętu:

Sprawdź optymalne rozmiary wejść/wyjść: cat /sys/block/nvme0n1/queue/optimal_io_size
cat /sys/block/nvme0n1/queue/max_hw_sectors_kb

Gdy już to wiesz, możesz ustalić rozsądną wartość, na przykład 1024 KB:

Ustaw max_sectors_kb: sudo sh -c 'echo 1024 > /sys/block/nvme0n1/queue/max_sectors_kb'

Dostrajanie powinowactwa procesora i pamięci NUMA dla NVMe

W nowoczesnych serwerach z wieloma procesorami lub gniazdami (NUMA) Opóźnienie dostępu do pamięci i urządzenia nie jest jednakoweDysk NVMe znajduje się fizycznie blisko konkretnego węzła NUMA i jeśli wątki, które go używają, znajdują się na innym węźle, każde wejście/wyjście przekracza magistralę między gniazdami, co powoduje wzrost opóźnienia.

Dlatego ważne jest zrozumienie zarówno przerwań NVMe, jak i procesów, które z nich korzystają. są podłączone do tego samego węzła NUMANajpierw sprawdź, z jakich IRQ korzysta dysk NVMe:

Zlokalizuj przerwania NVMe: grep -i nvme /proc/interrupts

Następnie możesz przypisać np. wszystkie IRQ z nvme0 do rdzeni 0-3:

Przypisz powinowactwo IRQ do jąder: for i in $(grep -i nvme0 /proc/interrupts | awk -F: '{print $1}'); do
echo 0-3 | sudo tee /proc/irq/$i/smp_affinity_list
done

Kiedy uruchamiasz swoją główną bazę danych lub usługę, nawet w wirtualizacja z KVM, używa numactl do naprawy procesora i pamięci do tego samego węzła:

Uruchom usługę za pomocą numactl: numactl --cpunodebind=0 --membind=0 tu-binario --tus-opciones

Kolejną małą zmianą w warstwie blokowej jest rq_affinityWskazuje sposób przetwarzania kolejek ukończenia wejścia/wyjścia. Wartość 2 wymusza obsługę ukończenia na tym samym rdzeniu, który wysłał żądanie, co poprawia lokalizację w pamięci podręcznej.

Aktywuj rq_affinity=2: echo 2 | sudo tee /sys/block/nvme0n1/queue/rq_affinity

Utrwal zmiany dostrajania NVMe za pomocą udev

Wszystkie zmiany dokonane poprzez dotknięcie plików w /sys Zostają utracone po ponownym uruchomieniuAby uniknąć konieczności ręcznego uruchamiania skryptów za każdym razem, najbezpieczniejszym podejściem jest użycie reguł udev, które dostosowują ustawienia natychmiast po wykryciu urządzenia przez jądro.

Na przykład, aby ustawić scheduler na none, rq_affinity na 2 i read_ahead na 128 KB na wszystkich dyskach NVMe, możesz utworzyć:

Utwórz regułę udev do dostrajania: sudo nano /etc/udev/rules.d/60-nvme-tuning.rules

Z treścią:

Przykład reguły udev: ACTION=="add|change", KERNEL=="nvme*n*", \
ATTR{queue/rq_affinity}="2", \
ATTR{queue/scheduler}="none", \
ATTR{queue/read_ahead_kb}="128"

Następnie przeładowujesz udev i uruchamiasz reguły:

Zastosuj reguły udev: sudo udevadm control --reload
sudo udevadm trigger

Jeśli chcesz mieć pewność, że wszystkie zmontowane jednostki skorzystają z Opcje takie jak noatime lub tmpfs dla katalogów tymczasowychPołącz te reguły z dobrą konfiguracją pliku /etc/fstab, co również zmniejszy liczbę zapisów i wydłuży żywotność dysków SSD i NVMe.

Wyrównanie partycji, sektor logiczny i TRIM na NVMe

Aby dysk NVMe działał prawidłowo w dłuższej perspektywie, same parametry jądra nie wystarczą: logiczna geometria partycji i wykorzystanie TRIMani technologie takie jak trwałe przechowywanie w pamięciMają one znaczenie, zwłaszcza w przypadku obciążeń baz danych i wirtualizacji, gdzie fragmentacja i nadpisywanie są zjawiskiem stałym.

Pierwszą rzeczą, którą należy zrobić, jest sprawdzenie, czy partycje są wyrównany do 1 MiBZazwyczaj dobrze pasuje to do wewnętrznej geometrii większości nowoczesnych dysków SSD. Dzięki parted możesz stworzyć przejrzysty układ:

Partycjonowanie wyrównane (rozdzielone): sudo parted -s /dev/nvme0n1 mklabel gpt
sudo parted -s /dev/nvme0n1 mkpart primary 1MiB 100%
sudo parted -s /dev/nvme0n1 align-check optimal 1

Ponadto wiele dysków NVMe oferuje różne formaty LBA (LBAF) z różnymi rozmiarami sektorówZazwyczaj 512B i 4K. Opcje i metrykę RP (wydajności względnej) można wyświetlić za pomocą:

Wyświetl formaty LBA: nvme id-ns -H /dev/nvme0n1 | grep -E 'LBA Format|Relative'

Jeśli zdecydujesz się na zmianę, pamiętaj, że jest to operacja destrukcyjna który usuwa całą zawartość dysku. Przykład wyboru formatu z indeksem 1:

Zmień format LBA (operacja destrukcyjna): sudo nvme format /dev/nvme0n1 --lbaf=1

W przypadku TRIM chodzi o to, aby poinformować jednostkę, które bloki nie zawierają już prawidłowych danych, aby mogła je ponownie je wykorzystać bez karyNajpierw sprawdź za pomocą lsblk, czy urządzenie obsługuje tę funkcję:

Sprawdź obsługę TRIM: lsblk --discard

Jeśli widzisz wartość DISC-GRAN różną od zera, oznacza to, że ta funkcja jest dostępna. Większość najnowszych dystrybucji ją obsługuje. tygodniowy timer fstrim która jest zalecaną opcją, lepszą niż użycie opcji discard w /etc/fstab, która dodaje obciążenie do każdego usunięcia:

Włącz okresowy fstrim: systemctl enable --now fstrim.timer
systemctl status fstrim.timer

Wybór i instalacja systemów plików na NVMe

Warstwa systemu plików stanowi ostatni filtr między aplikacją a dyskiem NVMe. XFS i ext4 działają bardzo dobrze na serwerach LinuxW większości przypadków zaleca się korzystanie z domyślnych opcji z niewielkimi zmianami mającymi na celu ograniczenie niepotrzebnych zapisów.

Bardzo skuteczną opcją, która nie ma prawie żadnych wad, jest nie ma czasuZapobiega to aktualizowaniu czasu ostatniego dostępu przy każdym odczycie pliku. Zmniejsza to liczbę zapisów na dysku, co poprawia zarówno żywotność pliku, jak i jego wydajność. Przykład w pliku /etc/fstab z systemem plików ext4:

Przykładowy fstab (ext4 noatime): /dev/nvme0n1p1 / ext4 noatime,errors=remount-ro 0 1

W przypadku XFS filozofia jest taka sama: użyj domyślnego systemu plików i dodaj noatime, jeśli chcesz jeszcze bardziej wydłużyć żywotność dysku SSD. W przypadku ext4 i XFS, Najlepiej okresowe TRIM z fstrim.timer zamiast opcji odrzucenia, z wyjątkiem bardzo specyficznych potrzeb.

Jeśli pracujesz z kartami SD lub nośnikami wymiennymi, pamiętaj, że wiele z nich korzysta FAT32 lub exFAT, który Nie mają funkcji dziennika ani TRIM.W takich przypadkach dostrajanie skupia się bardziej na wyborze kart o wyższej jakości i pojemności oraz na minimalizacji zapisu poprzez zmianę /var/log, /tmp lub katalogów z dużą ilością operacji wejścia/wyjścia na tmpfs, gdy ma to sens.

Ogólna optymalizacja dysków SSD/NVMe: noatime, tmpfs, swap i rejestrowanie

Oprócz dostrajania specyficznego dla NVMe, istnieje zestaw klasycznych poprawek dla dysków SSD, które nadal są bardzo skuteczne. Pierwsza z nich polega na sprawdzeniu, które katalogi są najbardziej obciążone. ciągłe czytanie i pisanie używając iotop:

Monitorowanie wejścia/wyjścia w czasie rzeczywistym: iotop -oPa

Pozostaw go na chwilę, a zobaczysz, które procesy i ścieżki mają pierwszeństwo. Stamtąd możesz przenieść niektóre katalogi o dużej zmienności do… tmpfs w pamięci RAMPod warunkiem, że masz dużo pamięci. Typowe przykłady w pliku /etc/fstab:

Przykład tmpfs w fstab: tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0

W wielu nowoczesnych dystrybucjach Linuksa katalog /tmp jest już katalogiem tmpfs, ale nadal można przenieść /var/tmp lub inne katalogi generujące duże ilości danych do pamięci RAM. Inną opcją jest /var/log, jeśli nie przeszkadza Ci utrata logów między restartami lub jeśli chcesz je przesłać do zdalnego sysloga.

tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0

Równolegle przejrzyj konfiguracja dziennika systemd w pliku /etc/systemd/journald.conf, aby ograniczyć maksymalny rozmiar dziennika (SystemMaxUse, RuntimeMaxUse itd.) oraz poziom szczegółowości (MaxLevelStore), unikając w ten sposób niepotrzebnych burz zapisu.

Kolejnym kluczowym punktem dla każdego dysku SSD lub NVMe jest użycie polityka swapów i swapowościZmniejszenie tej wartości pozwala jądru na efektywniejsze wykorzystanie pamięci RAM i redukuje użycie dysku:

Regulacja swapowości: vm.swappiness=1

Jeśli masz wyjątkowo dobrą pamięć i jesteś świadomy ryzyka, możesz nawet ustawić je na 0, chociaż w praktyce zwykle bardziej zrównoważone jest łączenie go z zram lub zswapktóre kompresują i zarządzają obszarem wymiany w pamięci przed dotarciem do dysku fizycznego, znacznie redukując liczbę zapisów na dysku NVMe.

Diagnozowanie rzeczywistych problemów w porównaniu z syntetycznymi testami porównawczymi (fio, dd, kopie plików)

Nierzadko zdarza się, że administrator spotyka się z sytuacją, fio daje doskonałe wyniki, ale proste kopiowanie pliku lub polecenie SELECT INTO bazy danych wydaje się śmiesznie wolneWażne jest, aby zdawać sobie sprawę, że obciążenia rzeczywiste nie zawsze odzwierciedlają idealny punkt odniesienia i że w grę wchodzi o wiele więcej czynników.

Polecenia takie jak dd z bs=1M Zwykle pokazują prędkości ograniczone przez warstwa systemu plików, pamięć podręczna stron jądra, sam dd i sposób, w jaki zapisujePodobnie, ogromna operacja w MSSQL, MySQL lub MariaDB na ext4 lub XFS obejmuje nie tylko NVMe, ale także dzienniki, synchronizację fsync, opróżnianie logów, blokowanie, procesor, harmonogram jądra i wiele więcej.

Jeżeli na serwerze z Epyc, dużą ilością pamięci RAM i dyskami NVMe wysokiej klasy widzisz, że kopie zapasowe nie przekraczają 1-2 GB/s, ale Fio podaje wartości bliskie specyfikacji, wąskim gardłem jest najprawdopodobniej warstwa oprogramowania (system plików, baza danych, konfiguracja dziennika, rozmiar dziennika itp.) lub w sposobie wykorzystania paralelizmu (liczba efektywnych wątków, ograniczenia współbieżności w bazie danych itd.).

Praktyczne podejście polega na połączeniu narzędzi niskiego poziomu (fio, iostat, smart-log) z pomiary na poziomie aplikacji i dostosowywać warstwowo: najpierw jądro i NVMe, następnie system plików i na końcu baza danych i same zapytania.

Rola sprzętu i systemu operacyjnego w wydajności bazy danych

Kiedy mówimy o strojeniu Bazy danych Jeśli chodzi o technologię NVMe, należy pamiętać, że domyślna konfiguracja rzadko jest wystarczająca do produkcji. Piramida wydajności zaczyna się od sprzętuProcesor, ilość pamięci RAM i przede wszystkim rodzaj magazynowanie.

U podstawy tej piramidy znajduje się jakość przechowywaniaDyski twarde nie sprawdzają się już w przypadku poważnych baz danych transakcyjnych; dyski SSD SATA to minimum akceptowalne; natomiast dyski NVMe podłączane przez PCIe są złotym standardem dzięki niskim opóźnieniom i bardzo wysokiej wydajności IOPS.

Powyżej znajduje się system operacyjny: jak sobie z nim radzi pamięć, pamięć podręczna stron, wejście/wyjście dysku i harmonogramowanie procesów Ma bezpośredni wpływ na bazę danych. Ustawienia takie jak stopień swappingu, wybór harmonogramu, użycie O_DIRECT w InnoDB, powinowactwo NUMA i montowanie katalogów w tmpfs mogą mieć większe znaczenie niż prosta zmiana parametrów wewnętrznych w MySQL.

Dopiero wtedy ma sens walczyć z konfiguracja serwera bazy danych (InnoDB, bufory globalne, logi itp.) oraz, na górze, projektowanie schematów i indeksów oraz jakość zapytań SQL.

MySQL/MariaDB na NVMe: dostrajanie InnoDB w celu wykorzystania możliwości sprzętu

InnoDB jest nowoczesnym domyślnym silnikiem pamięci masowej nie bez powodu: Oferuje transakcje ACID, blokowanie na poziomie wiersza, dobrą odporność na uszkodzenia i możliwość obsługi dużej współbieżności.Aby jednak naprawdę zabłysnąć, jego konfiguracja musi być zgodna ze sprzętem, na którym działa, zwłaszcza w przypadku szybkich dysków NVMe.

Parametr gwiazdy to innodb_buffer_pool_sizeDefiniuje ilość pamięci RAM, którą InnoDB przeznacza na przechowywanie danych i indeksów w pamięci. Zasadniczo na dedykowanym serwerze bazy danych od 70% do 80% dostępnej pamięci RAM jest zarezerwowane dla puli buforów, co jest dostosowywane do innych usług uruchomionych na komputerze.

Gdy dane mieszczą się głównie w puli buforów, odczyty są rozwiązywane w pamięci RAM, a NVMe jest używane głównie do sekwencyjne zapisy w dzienniku i kontrolowane opróżnianieW przeciwnym razie każde pominięcie pamięci podręcznej wiąże się z koniecznością odwiedzenia dysku, nawet jeśli jest to dysk NVMe, El Tiempo Czas reakcji będzie o rzędy wielkości wolniejszy niż w przypadku dostępu do pamięci.

Drugim ważnym blokiem strojenia jest Dzienniki InnoDB (innodb_log_file_size i innodb_log_buffer_size)Odpowiednio pojemny dziennik pozwala na grupowanie większej liczby zmian w długich sekwencyjnych zapisach, zmniejszając obciążenie plików danych spowodowane losowymi operacjami wejścia/wyjścia:

• Duży plik dziennika: Wyższa wydajność zapisu, ale dłuższy czas odzyskiwania danych po awarii, ponieważ konieczne jest odtworzenie większej liczby zdarzeń.
• Mały plik dziennika: Szybsza regeneracja, ale potencjalne wąskie gardło podczas intensywnego pisania.

Aby w pełni wykorzystać możliwości technologii NVMe, zazwyczaj warto mieć kłody nieco większe niż zwykleponieważ dysk może bez problemu obsługiwać sekwencyjne zapisy, a czas odzyskiwania danych jest zazwyczaj akceptowalny.

Współbieżność, wątki i wejście/wyjście w InnoDB przez NVMe

W środowiskach z wieloma procesorami i szybkimi dyskami NVMe kusząca może być konieczność zmiany parametrów, takich jak innodb_thread_concurrency, innodb_read_io_threads i innodb_write_io_threadsJednak w obecnych wersjach MySQL/MariaDB powszechną praktyką jest pozostawianie innodb_thread_concurrency na poziomie 0, aby moduł sam zarządzał wewnętrzną współbieżnością.

Ważne jest, aby mieć pewność, że na serwerze nie zabraknie miejsca. wątki do operacji odczytu i zapisu A niższa warstwa (jądro i NVMe) jest przygotowana do obsługi długich kolejek wejścia/wyjścia, gdy obciążenie tego faktycznie wymaga. W przypadku NVMe zazwyczaj nie ma problemu, ale zaleca się korzystanie z narzędzi takich jak Performance Schema lub Sys Scheme w celu sprawdzenia anomalii oczekiwania na wejście/wyjście.

Kluczowe znaczenie ma również interakcja InnoDB z systemem plików. Parametr innodb_flush_method=O_DIRECT W systemie Linux unika podwójnego buforowania z pamięcią podręczną systemu plików i zapisuje bezpośrednio na urządzeniu, co jest szczególnie zalecane w przypadku macierzy RAID z chronioną pamięcią podręczną lub NVMe z dobrą wewnętrzną pamięcią podręczną.

Zarządzanie połączeniami, bufory sesji i globalne pamięci podręczne

Szybki NVMe nie jest zbyt przydatny, jeśli serwer bazy danych jest przeciążony. tysiące nieaktywnych połączeń, gigantyczne bufory sesji lub przestarzała konfiguracja pamięci podręcznej zapytańDlatego oprócz dostrojenia InnoDB konieczne jest uporządkowanie parametrów ogólnych.

Niech zmienna max_połączenia Definiuje maksymalną liczbę dozwolonych jednoczesnych połączeń. Bezmyślne zwiększanie jej, bo „jest dużo pamięci RAM”, to błąd: każde połączenie obciąża bufory i struktury wewnętrzne, które kumulują się w pamięci. Najlepszą praktyką jest monitorowanie wartości Max_used_connections i Dostosuj max_connections nieznacznie powyżej rzeczywistego szczytu, zostawiając miejsce, ale nie przesadzając.

`wait_timeout` określa, jak długo bezczynne połączenie jest utrzymywane w stanie aktywności przed zamknięciem. Domyślne wartości w godzinach nie mają większego sensu w tym kontekście. aplikacje internetowe z pulami połączeńSkrócenie go do 60, a nawet 30 sekund pomaga w usuwaniu porzuconych sesji i zapobiega zapełnianiu pamięci połączeniami „uśpionymi”.

Parametr rozmiar_pamięci_wątkowej To ustawienie kontroluje liczbę wątków buforowanych do ponownego użycia w nowych połączeniach. Jeśli wartość parametru Threads_created jest znacznie wyższa niż wartość parametru Connections, oznacza to małą ilość pamięci podręcznej. Dostosowanie tego ustawienia zmniejsza koszt tworzenia wątków i poprawia responsywność podczas wzmożonego ruchu.

Jeśli chodzi o pamięć podręczną zapytań, jest ona przestarzała w nowoczesnym MySQL i zazwyczaj nie występuje w MariaDB. powodują więcej blokad i problemów z unieważnieniem niż korzyści w systemach o wysokiej szybkości zapisu. Nie oferuje niczego specjalnego w porównaniu z NVMe i w większości przypadków najlepiej go wyłączyć.

Bufory robocze na sesję: uważaj na pamięć

Parametry takie jak sort_buffer_size, join_buffer_size i read_buffer_size Są one przydzielane poszczególnym wątkom w razie potrzeby, co oznacza, że ​​ogromne wartości pomnożone przez setki połączeń mogą przy pełnej prędkości wyczerpać całą pamięć RAM.

Te bufory są używane do określonych operacji (sortowanie bezindeksowe, łączenie bezindeksowe, odczyty sekwencyjne) i powinny rosnąć tylko konkretne przypadki intensywnych i kontrolowanych konsultacjiOgólnie rzecz biorąc, lepiej jest zachować konserwatywne wartości i w razie potrzeby podwyższyć je w każdym przypadku indywidualnie podczas sesji konserwacyjnej lub procesu wsadowego, niż ustalać ogromne limity dla wszystkich klientów.

Projekt schematu, indeksu i zapytania: warstwa, na której generowany jest największy zysk

Niezależnie od tego, ile masz NVMe, dostrajania jądra i InnoDB, jeśli Twoje tabele nie są wystarczająco odpowiednie indeksy i zapytania wykonują pełne, masowe skanowanieSprzęt cię nie uratuje. Podstawowym narzędziem do sprawdzenia, co się dzieje, jest EXPLAIN.

Analizując plan wykonania, zwróć uwagę na:

• rodzaj: Jeśli w dużych tabelach widzisz ALL, oznacza to, że nastąpiło pełne skanowanie i musisz dodać indeksy.
• klucz i możliwe_klucze: które indeksy mogłyby być stosowane i które są faktycznie stosowane.
• wydziwianie: Szacunkowa liczba wierszy do sprawdzenia; im mniejsza, tym lepiej.

Prawidłowe indeksowanie jest kluczowe. kolumny używane w warunkach WHERE i JOIN...a także przepisywanie skorelowanych podzapytań w JOIN-ach, kiedy tylko jest to możliwe. Dobra konstrukcja indeksu zmniejsza liczbę operacji wejścia/wyjścia wymaganych na zapytanie, a tym samym lepiej wykorzystuje niskie opóźnienia NVMe.

Na poziomie schematu użyj typy danych tak małe, jak to możliweNormalizacja do rozsądnego poziomu i zdefiniowanie prostych kluczy podstawowych (INT/BIGINT AUTO_INCREMENT) w InnoDB pomaga w tworzeniu bardziej kompaktowych tabel, lepszym dopasowaniu ich do puli buforów oraz wykorzystaniu pamięci podręcznej i sprzętu bazowego.

Ciągły monitoring i iteracyjny cykl dostrajania

Całe to strojenie nie ma sensu, jeśli nie Mierzysz przed i po każdej zmiany. W przypadku bazy danych, dziennik wolnych zapytań, schemat wydajności i schemat sys umożliwiają lokalizację wolnych zapytań, tabel z wieloma pełnymi skanowaniami, niewykorzystanych indeksów lub plików, które koncentrują zbyt dużo operacji wejścia/wyjścia.

Narzędzia zewnętrzne, takie jak Prometheus/Grafana, Percona PMM lub inne systemy monitorujące Ułatwiają one dostrzeżenie szerszego obrazu: średniego opóźnienia i zapytań p95/p99, zapytań na sekundę (QPS), wykorzystania procesora, kolejek wejścia/wyjścia, temperatury i kondycji NVMe itd. Dzięki tym informacjom można zastosować sensowny proces iteracyjny:

• Zdefiniuj poziom bazowy wydajności (sprzęt + jądro + baza danych).
• Zidentyfikuj dominujące wówczas wąskie gardło.
• Zastosuj pojedynczą zmianę (np. dostosuj pulę buforów, zmień harmonogram lub dodaj indeks).
• Dokonaj ponownego pomiaru i zadecyduj, czy zmiana pozostanie, zostanie cofnięta, czy zmodyfikowana.

Optymalizacja NVMe i baz danych w systemie Linux nie jest magiczną sztuczką ani odosobnioną zmianą parametrów, lecz ciągły proces pomiaru, zrozumienia i dostosowywania warstwowoŁącząc dobry sprzęt (szczególnie wysokiej jakości dysk NVMe), dobrze dostrojone jądro (APST, harmonogram, NUMA, TRIM), inteligentnie skonfigurowane systemy plików (noatime, tmpfs w stosownych przypadkach) oraz dobrze sparametryzowany system MySQL/MariaDB z solidnymi schematami i indeksami, można sprawić, że serwery Linux w pełni wykorzystają potencjał dysków NVMe w rzeczywistych obciążeniach, wykraczających poza syntetyczne testy laboratoryjne.