Optymalizacja harmonogramu operacji wejścia/wyjścia w systemie Linux: mq-deadline, none i BFQ

Harmonogram I/O systemu Linux decyduje o kolejności, w jakiej żądania odczytu i zapisu docierają do urządzenia pamięci masowej, a właściwy wybór zależy prawie wyłącznie od posiadanego sprzętu. Użyj none dla NVMe, mq-deadline dla dysków SSD i HDD SATA obsługujących mieszane obciążenia oraz bfq gdy chcesz zapobiec sytuacji, w której jeden proces blokuje pozostałe. W tym przewodniku omówiono działanie trzech głównych harmonogramów, sposób dopasowania ich do obciążenia oraz sposób dostrajania i weryfikacji wyników.

Jeśli przed lekturą chcesz zapoznać się z praktycznym przewodnikiem, ten film przedstawia podstawy przełączania i testowania harmonogramów z poziomu terminala.

Czym różnią się mq-deadline, none i BFQ

Każdy harmonogram obsługuje żądania według innej strategii. Znajomość różnic między nimi pozwala na świadomy wybór, zamiast korzystania z tego, co wybrało jądro podczas uruchamiania.

mq-deadline

Ten mq-deadline zapewnia, że żadne żądanie nie czeka w nieskończoność. Utrzymuje oddzielne, posortowane kolejki dla odczytów i zapisów, porządkując je według logicznego adresu bloku (LBA), aby skrócić czas wyszukiwania, oraz egzekwuje terminy: domyślnie 500 ms dla odczytów i 5 sekund dla zapisów. Gdy żądanie osiągnie swój termin, przeskakuje na początek kolejki.

Odczyty mają pierwszeństwo przed zapisami, ponieważ odczyty zazwyczaj blokują aplikację, podczas gdy zapisy są obsługiwane asynchronicznie. Aby zapobiec całkowitemu zablokowaniu zapisów, harmonogram obsługuje partię zaległych zapisów po określonej liczbie odczytów. Efektem jest stałe niskie opóźnienie, co sprawia, że harmonogram ten doskonale nadaje się do serwerów baz danych i wszelkich obciążeń łączących odczyty i zapisy.

brak

Harmonogram none harmonogram prawie nic nie robi. Przekazuje żądania bezpośrednio do urządzenia w kolejności „pierwsze weszło, pierwsze wyszło”, bez zmiany kolejności, scalania ani ustalania priorytetów. To pasuje do nowoczesnych dysków NVMe, które zarządzają własnymi wewnętrznymi kolejkami i mogą śledzić jednocześnie dziesiątki tysięcy żądań w trakcie przetwarzania. Usunięcie warstwy oprogramowania do planowania zapewnia najkrótszą możliwą ścieżkę od aplikacji do urządzenia, a to jest dokładnie to, czego potrzebują obciążenia NVMe o wysokiej przepustowości.

Haczyk polega na tym, że działa to tylko wtedy, gdy sprzęt potrafi samodzielnie inteligentnie planować. W przypadku dysków HDD lub dysków SSD SATA z płytkimi kolejkami pominięcie programowego porządkowania zazwyczaj pogarsza wydajność, a nie ją poprawia.

BFQ

BFQ (Budget Fair Queuing) stawia sprawiedliwość na pierwszym miejscu. Zamiast przedziałów czasowych, przydziela każdemu procesowi budżet mierzony w sektorach dysku. Duże sekwencyjne operacje odczytu otrzymują większe budżety, aby utrzymać przepustowość, podczas gdy zadania wrażliwe na opóźnienia otrzymują mniejsze budżety, dzięki czemu są obsługiwane szybko, a pętla sprzężenia zwrotnego dostosowuje budżety w trakcie działania.

BFQ zapewnia responsywność zadań interaktywnych nawet przy dużym obciążeniu, dzięki czemu odtwarzanie wideo lub zapytania do bazy danych przebiegają płynnie, podczas gdy w tle trwa transfer dużych plików. Ta sprawiedliwość ma jednak swoją cenę w postaci obciążenia procesora. Obciążenie na żądanie wynosi około 1,9 mikrosekundy, czyli około trzy razy więcej niż w przypadku mq-deadline, a na wolniejszym rdzeniu ARM ogranicza przepustowość znacznie poniżej poziomu osiąganego przez ten sam harmonogram na szybkim układzie x86. Na serwerach, gdzie najważniejsza jest surowa przepustowość i wydajność procesora, trudno jest uzasadnić ten kompromis.

Dopasowanie harmonogramu do obciążenia

O wyborze odpowiedniego harmonogramu decydują dwie rzeczy: sprzęt pamięci masowej oraz wzorzec dostępu aplikacji. Zacznijmy od sprzętu. Jeśli urządzenie już zmienia kolejność żądań, jak na przykład dysk NVMe z odpowiednim oprogramowaniem układowym, harmonogramowanie programowe tylko zwiększa obciążenie, więc none wygrywa. W przypadku obracających się dysków twardych, gdzie dominuje czas wyszukiwania, programowa zmiana kolejności zmniejsza opóźnienie, więc mq-deadline lub bfq są lepszym wyborem. Dyski SSD SATA plasują się pomiędzy: są szybsze niż dyski HDD, ale nie mają głębokich kolejek NVMe, co sprawia, że mq-deadline pasuje.

Ta sama logika ma zastosowanie, gdy coś innego już planuje za Ciebie. Maszyny wirtualne gości na virtio-blk polegają na hoście w zakresie planowania operacji we/wy, a sprzętowe kontrolery RAID z pamięcią podręczną typu write-back optymalizują własną kolejność. W obu przypadkach none unika się podwójnego obciążania pracą.

Wzorzec dostępu jest drugim czynnikiem. Baza danych wykonująca tysiące losowych odczytów 4K na sekundę nie ma nic wspólnego z zadaniem szkoleniowym przesyłającym strumieniowo duże sekwencyjne bloki z macierzy NVMe i wymagają one różnych harmonogramów. Poniższa tabela przyporządkowuje typowe obciążenia do punktu wyjścia.

Jest jeden wyjątek, o którym warto wspomnieć. Nawet w przypadku NVMe, jeśli interesuje Cię opóźnienie ogona na poziomie p99 lub p999, na przykład w systemach finansowych, mq-deadline może to przewyższyć none dzięki egzekwowaniu ścisłych terminów i zapobieganiu sporadycznym opóźnieniom żądań.

Zmiana i dostosowywanie parametrów harmonogramu

Zarówno przełączanie harmonogramów, jak i dostosowywanie ich parametrów odbywa się za pośrednictwem sysfs, a do przetestowania zmiany nie jest wymagane ponowne uruchomienie systemu.

Zmiana aktywnego harmonogramu

Sprawdź, co jest dostępne dla danego urządzenia, gdzie wartość w nawiasach jest wartością aktywną:

cat /sys/block/sda/queue/scheduler

Przełącz na inny harmonogram w czasie wykonywania. Zmiana ta zaczyna obowiązywać natychmiast, ale nie przetrwa ponownego uruchomienia:

echo bfq | sudo tee /sys/block/sda/queue/scheduler

Jeśli bfq nie ma na liście, najpierw załaduj moduł:

sudo modprobe bfq

Aby wybór był trwały, użyj reguły udev zamiast starego elevator= parametr jądra, który w RHEL 9 i podobnych wydaniach już nie zmienia harmonogramu. Ta reguła ustawia mq-deadline dla wszystkich dysków SCSI bez rotacji w /etc/udev/rules.d/60-io-scheduler.rules:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"

Przeładuj i zastosuj ją bez restartu:

sudo udevadm control --reload-rules && sudo udevadm trigger

W systemach opartych na RHEL profile TuneD wykonują tę samą pracę poprzez profile systemowe zamiast reguł dla poszczególnych urządzeń.

Parametry warte dostrojenia

Każdy harmonogram udostępnia swoje parametry regulacyjne w /sys/block/<device>/queue/iosched/. W przypadku mq-deadline, terminy są głównymi dźwigniami. Bazy danych wrażliwe na opóźnienia na dyskach SSD SATA zyskują na krótszych terminach:

echo 100 | sudo tee /sys/block/sda/queue/iosched/read_expire
echo 1000 | sudo tee /sys/block/sda/queue/iosched/write_expire

W bfq systemów o wysokiej przepustowości wyłączenie heurystyki opóźnień zwiększa przepustowość:

echo 0 | sudo tee /sys/block/sda/queue/iosched/low_latency
echo 0 | sudo tee /sys/block/sda/queue/iosched/slice_idle

W przypadku hostingu współdzielonego BFQ dobrze współpracuje z cgroups v2. Przypisanie io.weight wartości pozwala na przykład przyznać procesowi bazy danych dziesięciokrotność udziału we wczytywaniu/zapisywaniu w porównaniu z zadaniem tworzenia kopii zapasowej, dzięki czemu zadania w tle nie mogą zagłuszyć ruchu interaktywnego. Niezależnie od wprowadzanych zmian, wyższy koszt BFQ na żądanie sumuje się w systemach obciążonych procesorem i wymagających wysokiej liczby operacji IOPS, dlatego przed wdrożeniem należy przeprowadzić testy porównawcze.

Weryfikacja wydajności po optymalizacji

Zawsze należy zarejestrować stan wyjściowy przed wprowadzeniem jakichkolwiek zmian. Bez tego nie ma możliwości stwierdzenia, czy dane dostosowanie przyniosło oczekiwane rezultaty.

fio jest standardowym narzędziem do tego celu. Odtwarza ono konkretne wzorce obciążenia poprzez ustawienia rozmiaru bloku, głębokości kolejki i silnika we/wy. Zawsze należy przekazać --direct=1 , aby ominąć pamięć podręczną stron i mierzyć bezpośrednio harmonogram oraz urządzenie, a nie odczyty z pamięci podręcznej. Dopasuj test do rzeczywistego obciążenia:

Przeprowadź ten sam test dla iodepth wartości od 1 do 256, aby znaleźć punkt nasycenia urządzenia, czyli poziom, na którym IOPS przestają rosnąć, a opóźnienia gwałtownie wzrastają. W celu monitorowania na żywo po wprowadzeniu zmiany iostat -x 1 przedstawia istotne wskaźniki: r_await oraz w_await opóźnienie zakończenia odczytu i zapisu, aqu-sz dla średniej głębokości kolejki oraz %util dla wykorzystania urządzenia. Gdy %util wynosi blisko 100 procent, ograniczeniem jest sprzęt i żadna zmiana harmonogramu nie pomoże.

Aby oddzielić koszt oprogramowania od kosztu sprzętu, uruchom blktrace z btt. Dzieli to opóźnienie na Q2D, czyli czas spędzony w kolejce oprogramowania, oraz D2C, czyli czas, jaki urządzenie potrzebuje na obsługę żądania. Jeśli dominuje Q2D, wąskim gardłem jest harmonogram. Jeśli dominuje D2C, wąskim gardłem jest sprzęt.

Jedna rzecz, o której należy pamiętać podczas analizy wyników: wybór harmonogramu wpływa głównie na ogon rozkładu opóźnień, a nie na medianę. Przejście z none na mq-deadline na NVMe może nieznacznie zwiększyć medianę opóźnienia o kilka mikrosekund, jednocześnie zmniejszając opóźnienie p99 i p999 o połowę. W przypadku usług dla użytkowników objętych umowami SLA taki kompromis prawie zawsze się opłaca, dlatego celem tego ćwiczenia jest pomiar opóźnienia ogona, a nie średniej przepustowości.

Wybór odpowiedniego harmonogramu

Dostrajanie harmonogramu polega na dopasowaniu algorytmu do sprzętu i wzorca dostępu, a następnie sprawdzeniu go za pomocą pomiarów. W skrócie:

• NVMe: użyj none i pozwól oprogramowaniu układowemu zająć się kolejkowaniem.
• Dyski SSD i HDD SATA z mieszanym wejściem/wyjściem: użyj mq-deadline , aby uzyskać przewidywalne opóźnienia.
• Hosty współdzielone lub wielodostępne: użyj bfq , aby jedno obciążenie nie blokowało pozostałych.
• Śledź opóźnienie ogona, a nie medianę: zmiany w harmonogramie pojawiają się przy p99 i p999, więc to właśnie należy mierzyć.
• Zapewnij trwałość: używaj reguł udev lub TuneD, nigdy nieaktualnego elevator= .

Wykorzystanie w pełni możliwości dowolnego harmonogramu zaczyna się od sprzętu, który nadąża za wymaganiami. Jeśli potrzebujesz serwerów opartych na NVMe, zbudowanych z myślą o obciążeniach o wysokiej przepustowości i niskim opóźnieniu, zapoznaj się z opcjami VPS firmy FDC.