Optymalizacja ZFS ARC: limity, ograniczenia i co należy mierzyć

ZFS domyślnie zajmuje około połowy pamięci RAM systemu na swoją pamięć podręczną odczytu, a na nieodpowiednim serwerze oznacza to aktywność pamięci wymiany, zabijanie procesów z powodu braku pamięci (OOM) lub rywalizację bazy danych z systemem plików o pamięć. Optymalizacja ARC w ZFS polega na ustaleniu, ile z tej pamięci RAM ARC może faktycznie zachować oraz z czego trzeba zrezygnować, aby ustawić ten limit. W tym wpisie omówiono sposób wykorzystania pamięci przez ARC, co należy zmierzyć przed podjęciem jakichkolwiek działań, kilka parametrów, które warto zmienić, oraz rozsądne wartości początkowe dla serwerów plików, hiperwizorów, baz danych i miejsc docelowych kopii zapasowych. Jeśli chodzi o migawki w systemie ZFS, zapoznaj się z naszym przewodnikiem po migawkach ZFS.

Zmierz wskaźnik ARC, zanim zaczniesz cokolwiek dostosowywać

Nie zmieniaj żadnego parametru, dopóki nie uzyskasz danych bazowych z normalnego okresu wzmożonego ruchu. Migawki z okresów spokoju wprowadzą cię w błąd. Nocne kopie zapasowe, cotygodniowe raporty i zadania wsadowe to zazwyczaj sytuacje, w których zachowanie ARC staje się interesujące, więc zbieraj dane z kilku dni.

Trzy narzędzia pokrywają większość potrzeb:

• arcstat 1 zapewnia na bieżąco przewijany widok liczników trafień i pominięć, aktywności związanej z zapotrzebowaniem w porównaniu z prefetchem oraz aktualnego rozmiaru ARC. Używaj go podczas testów obciążeniowych i w oknach tworzenia kopii zapasowych.
• arc_summary wyświetla pojedynczą migawkę: rozmiar i wartość docelową ARC, podział MFU/MRU, współczynniki metadanych oraz aktywne parametry regulacyjne. Uruchom polecenie arc_summary -s arc tylko dla sekcji ARC.
• Surowe liczniki działają /proc/spl/kstat/zfs/arcstats w systemie Linux oraz w sekcji kstat.zfs.misc oraz vfs.zfs drzewach sysctl w systemie FreeBSD. Należy je pobierać z systemu monitorowania, zamiast analizować sformatowane dane wyjściowe.

Liczniki, które warto zarejestrować przed wprowadzeniem jakichkolwiek zmian:

Są dwie rzeczy, które ludzie często mylą w tym kontekście. Należy obserwować pamięć dostępną, a nie wolną; system Linux bez problemu zgłasza niski poziom wolnej pamięci RAM jako stan stabilny, a samo to nie stanowi problemu. Istotnym sygnałem jest pamięć dostępna bliska zeru w połączeniu z utrzymującą się aktywnością wymiany (podręcznik zarządzania pamięcią w systemie Linux wyjaśnia, dlaczego). Należy też traktować współczynnik trafień jako trend, a nie cel. Współczynnik trafień na poziomie 99% na komputerze, na którym odbywa się wymiana, oznacza niepowodzenie w dostrajaniu, a nie sukces.

Cztery istotne parametry regulacyjne ARC

Większość dostrajania w środowisku produkcyjnym sprowadza się do czterech ustawień. Dopasuj ustawienie do ciśnienia faktycznie zmierzonego w pomiarach bazowych. Aktywność wymiany wskazuje na zfs_arc_max. Odzyskiwanie danych, które ciągle czyszczą gorącą pamięć podręczną, wskazuje na zfs_arc_min. Powolne przeszukiwanie katalogów wskazuje na limit metadanych.

Zacznij od najmniejszej zmiany, która rozwiązuje zauważony problem. W zfs_arc_max, właściwy pułap zależy od obciążenia (omówione w następnej sekcji). W przypadku zfs_arc_minwartość minimalna wynosząca od 25% do 50% zfs_arc_max jest rozsądnym punktem wyjścia, jeśli w ogóle jest on potrzebny. W przypadku metadanych najnowsze domyślne ustawienia OpenZFS już przydzielają im 75% ARC poprzez zfs_arc_meta_limit_percent, co jest wartością wystarczającą dla większości obciążeń; należy to zmieniać tylko wtedy, gdy braki metadanych są wyraźnie widoczne w arcstat.

Wdrażanie zmian w systemach Linux i FreeBSD

W systemie Linux zmianę można przetestować w trakcie działania systemu, zapisując ją w pliku parametrów sysfs. Nie jest wymagane ponowne uruchomienie systemu:

echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max

Spowoduje to zfs_arc_max wartość na 16 GiB. Aby zmiana przetrwała restart, dodaj ją do /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

W systemie FreeBSD zmiany w czasie wykonywania wykorzystują sysctl:

sysctl vfs.zfs.arc_max=17179869184

Aby zachować tę samą wartość w /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Zmieniaj po jednym ustawieniu na raz, małymi krokami wynoszącymi około 10% całkowitej pamięci RAM. Obserwuj okno z problemami. Zachowaj zmianę tylko wtedy, gdy wymiana pozostaje na poziomie zero, a opóźnienie jest stabilne. Utrwal zmianę dopiero po pomyślnym zakończeniu testu w trakcie działania systemu.

Dostosowanie ARC do obciążenia

Całkowita pojemność pamięci RAM nie jest właściwym punktem wyjścia. Wymiarowanie pamięci ARC powinno opierać się na strukturze obciążenia danego urządzenia.

Host maszyn wirtualnych musi dzielić pamięć ze swoimi gośćmi, więc limit od 30% do 40% jest bezpiecznym ustawieniem domyślnym, a 50% to już zbyt wysoka wartość w większości konfiguracji. Bazy danych, takie jak PostgreSQL i MySQL, zarządzają własnymi pamięciami podręcznymi, więc najpierw rezerwuje się pamięć dla silnika, a resztę pozostawia się dla ARC. Miejsca docelowe kopii zapasowych czerpią korzyści z primarycache=metadata ponieważ odczytywane dane rzadko są ponownie potrzebne, a nie chcesz, aby nocna kopia zapasowa przeszukiwała całą pulę i opróżniała resztę pamięci podręcznej po drodze. We wszystkich obciążeniach aktywność wymiany, gdy ARC jest przypięty na poziomie zfs_arc_max oznacza, że limit jest zbyt wysoki; ta zasada pozostaje niezmienna.

Diagnozowanie problemów i wiedza, kiedy przestać

Zbyt mała pamięć ARC objawia się wysoką liczbą operacji IOPS odczytu, niskim współczynnikiem trafień zapytań oraz powolnym przeglądaniem katalogów, podczas gdy system nadal dysponuje wolną pamięcią RAM. Zbyt duża pamięć ARC jest mniej oczywista. Współczynnik trafień wygląda dobrze, ale serwer zaczyna korzystać z pamięci wymiany, średnie obciążenie rośnie, procesy blokują się w D stanie, podczas gdy jądro odzyskuje strony ARC na żądanie, a w najgorszym przypadku mechanizm OOM killer zaczyna wybierać ofiary. Pamięć podręczna wygląda na sprawną, a serwer działa fatalnie.

Obciążenie metadanymi ujawnia się, gdy demand_metadata_bytes znacznie przewyższa demand_data_bytes w arc_summary. Oznacza to, że metadane walczą o miejsce z danymi i warto podnieść limit procentowy metadanych.

Porównaj to, co widzisz, z pierwszym ustawieniem, które należy sprawdzić:

L2ARC nie jest bezpłatny. Indeks wpisów L2ARC znajduje się w głównym ARC, a jeśli to obciążenie przekroczy około jednej trzeciej całkowitej pojemności ARC, pamięć podręczna drugiego poziomu przynosi więcej szkody niż pożytku. Z L2ARC należy korzystać tylko wtedy, gdy zestaw roboczy jest większy niż pamięć RAM, ale nadal mieści się na szybkim urządzeniu NVMe, i tylko wtedy, gdy współczynnik trafień w głównej pamięci ARC jest już na dobrym poziomie.

Właściwym momentem na zaprzestanie optymalizacji jest sytuacja, gdy opóźnienie pozostaje na stałym poziomie, wymiana danych na dysk pozostaje na poziomie zerowym w tym samym oknie obciążenia, które spowodowało pierwotny problem, a dalsze zmiany nie przynoszą już żadnych korzyści. Wysoki współczynnik trafień nie ma znaczenia, jeśli serwer korzysta z wymiany danych na dysk. Po osiągnięciu tego punktu należy zaprzestać dostosowywania ustawień i powrócić do nich tylko wtedy, gdy ten sam problem powróci przy takim samym obciążeniu.

Jeśli potrzebujesz serwera z wystarczającą rezerwą pamięci RAM, aby poprawnie uruchamiać system plików ZFS bez rywalizacji o pamięć z maszynami wirtualnymi lub bazami danych (warto najpierw przeczytać, ile pamięci RAM faktycznie potrzebujesz), zapoznaj się z ofertą serwerów dedykowanych FDC.