Więcej pamięci RAM czy dublowana warstwa metadanych na dysku SSD przy obciążeniu pamięci podręcznej ARC w ZFS: którą modernizację wybrać najpierw?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

More RAM vs a Mirrored SSD Metadata Tier for ZFS ARC Pressure: Which Upgrade Comes First? - Zima Store Online

Najpierw dodaj pamięć RAM, gdy ARC ZFS wielokrotnie się kurczy, często używane metadane są eksmitowane, aplikacje konkurują z systemem plików lub serwer korzysta ze stronicowania. Dodaj dublowany special vdev na SSD, gdy pamięci jest już wystarczająco dużo, ale przechodzenie po zimnych katalogach, operacje na migawkach i chybienia metadanych nadal wymuszają losowe operacje wejścia-wyjścia na dysku HDD. Warstwa SSD zmniejsza koszt chybienia, ale nie zwiększa pojemności ARC i staje się trwałą częścią puli.

Bramka 1: Oddziel presję na pamięć od opóźnień pamięci masowej

„Presja na ARC” powinna opisywać zaobserwowany stan, a nie po prostu pełny wykres pamięci. ZFS celowo wykorzystuje dostępną pamięć RAM na ARC i może ją zwolnić, gdy aplikacje jej potrzebują. Problem zaczyna się, gdy użyteczny zestaw roboczy nie pozostaje już w pamięci, ARC wielokrotnie się kurczy, spada współczynnik trafień metadanych lub system operacyjny zaczyna intensywnie odzyskiwać pamięć i korzystać ze stronicowania.

Wyjaśnienie ZimaSpace dotyczące presji na pamięć podręczną metadanych powodowanej przez bardzo dużą liczbę plików przedstawia powiązany mechanizm. Ten artykuł pomaga podjąć decyzję o modernizacji: czy brakuje zmiennej pojemności pamięci podręcznej, czy szybszej, trwałej ścieżki dostępu do metadanych.

Uruchom to samo zadanie dwukrotnie. Jeśli powtórzenie po rozgrzaniu jest szybkie, ale uruchomienie na zimno trwa długo, znaczenie mają chybienia pamięci masowej. Jeśli oba uruchomienia pogarszają się, gdy aplikacje zużywają pamięć RAM, pierwszym wąskim gardłem jest przydzielanie pamięci. Jeśli żaden z tych wzorców nie pasuje, przerwij porównanie i sprawdź procesor, sieć, blokady, fragmentację oraz aplikację.

Bramka 2: Wybierz więcej pamięci RAM, gdy gorący zestaw danych nie może pozostać w ARC

Pamięć RAM to najszybsze miejsce dla często używanych danych i metadanych. Większa ilość pamięci może utrzymywać wpisy katalogów, bloki pośrednie, dane plików i robocze zestawy aplikacji w pamięci, bez konieczności odwoływania się do innego urządzenia. Daje też ZFS więcej przestrzeni na dostosowywanie się między blokami ostatnio używanymi a blokami często odczytywanymi.

Klara Systems zauważa, że więcej pamięci RAM jest często lepszą pierwszą inwestycją w pamięć podręczną niż dodanie vdev CACHE. Ta rada jest szczególnie istotna, gdy system ma mało pamięci w stosunku do liczby uruchomionych usług lub gdy L2ARC zużywałby dodatkowe nagłówki ARC.

Wybór pada na pamięć RAM, gdy NAS uruchamia także kontenery, bazy danych, maszyny wirtualne, indeksowanie multimediów lub lokalną sztuczną inteligencję. Warstwa metadanych na SSD może przyspieszyć dostęp do metadanych puli, ale nie zapewni pamięci sterty aplikacji, pamięci gościa, pamięci jądra ani miejsca w ARC. Najpierw rozwiąż problem współdzielonego niedoboru pamięci, zanim wyspecjalizujesz układ pamięci masowej.

Bramka 3: Wybierz warstwę metadanych na SSD, gdy koszt chybień cache nadal jest wysoki

Specjalny vdev trwale przechowuje wybrane klasy bloków na szybszych urządzeniach. Domyślnie obejmuje to metadane systemu plików i bloki pośrednie; może również przechowywać małe bloki danych, gdy zostanie to skonfigurowane dla zbioru danych. Zmienia to miejsce przechowywania metadanych nawet po ponownym uruchomieniu systemu i zanim ARC się rozgrzeje.

Wskazówki Klara dotyczące optymalizacji ZFS opisują umieszczanie metadanych i wybranych małych bloków na specjalnym vdev przy jednoczesnym przechowywaniu danych zbiorczych na dyskach HDD. Korzyści są największe w przypadku rekurencyjnych skanowań przy zimnej pamięci, dużych drzew katalogów, repozytoriów intensywnie korzystających z migawek oraz obciążeń, w których wiele losowych odczytów metadanych wielokrotnie nie trafia do RAM-u.

Ta warstwa nie zmniejsza presji na pamięć aplikacji. Sprawia jedynie, że chybiony odczyt kosztuje mniej. Jeśli ARC po rozgrzaniu i tak buforuje aktywne metadane, a użytkownicy rzadko wykonują skanowania przy zimnej pamięci, specjalny vdev może zapewnić imponujące wyniki syntetyczne bez zmiany codziennej pracy.

Zaobserwowany stan	Najpierw więcej RAM-u	Najpierw lustrzana warstwa metadanych na SSD
ARC zmniejsza się, gdy rośnie zapotrzebowanie aplikacji lub maszyn wirtualnych	Bardzo dobre rozwiązanie	Nie rozwiązuje problemu współdzielonego niedoboru pamięci
System intensywnie korzysta z pliku stronicowania lub występuje presja na odzyskiwanie pamięci	Wymagane przed specjalizacją pamięci masowej	Może dodać kolejne obciążenie bez rozwiązania problemu braku pamięci
Powtórny odczyt jest szybki, a przejście po katalogach przy zimnej pamięci — wolne	Może pomóc, jeśli zbiór metadanych mieści się w pamięci	Bardzo dobre rozwiązanie, gdy zbiór jest większy niż praktyczna pojemność ARC
Usuwanie migawek i skanowanie rekurencyjne wymaga przeszukiwania dysków HDD	Pomaga tylko wtedy, gdy odpowiednie metadane pozostają w pamięci podręcznej	Przenosi trwały dostęp do metadanych na SSD
Maszyny wirtualne i bazy danych potrzebują dedykowanej pamięci flash	Przydatne, ale nie jest zasadą rozmieszczania danych	Oddzielna pula SSD może być lepszym rozwiązaniem niż specjalny vdev
Tolerancja awarii	Uszkodzony moduł DIMM lub host nadal wymagają planu odzyskiwania	Specjalny vdev musi odpowiadać wymaganiom puli dotyczącym redundancji i kopii zapasowych
Odwracalność	Zwykle łatwe dodawanie lub usuwanie w granicach możliwości platformy	Trwała architektura puli wymagająca starannej migracji

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Nie myl specjalnego vdev, L2ARC i oddzielnej puli SSD

ARC to podstawowa pamięć podręczna w RAM-ie. L2ARC to opcjonalna dodatkowa pamięć podręczna odczytu na vdev typu CACHE. Specjalny vdev nie jest pamięcią podręczną — przechowuje trwale określone klasy alokacji. Oddzielna pula SSD lub dedykowany zbiór danych SSD to kolejny system pamięci masowej z własną pojemnością, migawkami, replikacją i ścieżką odzyskiwania.

OpenZFS wyraźnie rozróżnia te pojęcia: ARC, L2ARC, SLOG i specjalne klasy alokacji pełnią różne funkcje. Traktowanie ich jako wymiennych urządzeń „pamięci podręcznej SSD” prowadzi do niewłaściwej modernizacji i może powodować nieoczekiwane ryzyko utraty danych.

Jeśli wiadomo, że często używane pliki to zbiory danych aplikacji, dyski maszyn wirtualnych, bazy danych lub stan kontenerów, niezależna, dublowana pula SSD może być łatwiejsza do zrozumienia niż kierowanie małych bloków przez klasę specjalną. Jeśli problem dotyczy metadanych w całej puli dysków HDD, specjalny vdev jest bardziej bezpośrednią architekturą.

Domena awarii może odwrócić wybór pod względem wydajności

Specjalny vdev przechowuje krytyczne bloki puli. Powinien być chroniony takim samym lub wyższym poziomem nadmiarowości jak vdevy danych i monitorowany jak podstawowa pamięć masowa. Utrata niechronionego specjalnego vdev może sprawić, że pula stanie się niedostępna lub niemożliwa do odzyskania, ponieważ metadane nie są jedynie zbędną kopią przyspieszającą działanie.

OpenZFS opisuje urządzenie specjalne jako stały vdev najwyższego poziomu przeznaczony dla metadanych i wybranych klas bloków. Dlatego pojedynczego konsumenckiego dysku SSD nie należy pochopnie dodawać w celu przyspieszenia nadmiarowej puli dysków HDD.

Większa ilość pamięci RAM jest zwykle łatwiejsza do wycofania. Specjalny vdev zmienia model awarii puli, wymagania dotyczące wytrzymałości dysków SSD, plan wymiany oraz procedurę migracji. Jeśli właściciel nie potrafi wyjaśnić, jak wymienić oba urządzenia w mirrorze ani jak odtworzyć pulę po ich utracie, pamięć RAM jest bezpieczniejszym pierwszym eksperymentem.

Kiedy L2ARC pomaga, ale nadal nie zastępuje pamięci RAM

L2ARC może rozszerzyć buforowanie odczytu, gdy aktywny zbiór danych przekracza pojemność ARC, a powtarzające się odczyty uzasadniają wyszukiwanie na dysku SSD. Wymaga czasu na rozgrzanie i zużywa pamięć ARC na nagłówki, więc w systemie z poważnym niedoborem pamięci może przynieść odwrotny skutek. Nie przenosi też metadanych na stałe w sposób, w jaki robi to specjalny vdev.

Bieżąca analiza firmy Klara dotycząca działania L2ARC przy ograniczeniach pamięci RAM wyjaśnia koszt nagłówków oraz konieczność sprawdzenia `arcstats` przed dobraniem rozmiaru urządzenia. Używaj L2ARC, gdy potwierdzono powtarzające się chybienia odczytu, a rozbudowa pamięci RAM jest ograniczona, a nie jako automatycznego rozwiązania problemu z metadanymi.

Jeśli obciążenie polega głównie na jednorazowym przechodzeniu po danych bez rozgrzanej pamięci podręcznej, L2ARC może nigdy nie przechować odpowiednich bloków wystarczająco długo, aby pomóc. Jeśli obciążenie się powtarza, a ARC nie może go pomieścić, L2ARC może być trzecią opcją po rozdzieleniu kwestii pamięci RAM i specjalnego vdev.

Zastosuj kontrolowaną sekwencję rozbudowy

Zapisz rozmiar ARC, rozmiar metadanych, współczynniki trafień, eksmisje, odzyskiwanie pamięci oraz stronicowanie systemu.
Zmierz czas wolnego zadania, a następnie powtórz je po rozgrzaniu pamięci podręcznej.
Tymczasowo ogranicz działanie konkurujących aplikacji lub pamięć maszyn wirtualnych i powtórz zadanie.
Dodaj pamięć RAM lub zwiększ bezpieczny limit ARC, jeśli platforma na to pozwala, a następnie ponów test.
Po usunięciu presji na pamięć zmierz losowe operacje wejścia-wyjścia dysków HDD podczas operacji na zimnych metadanych.
Oszacuj pojemność, wytrzymałość, redundancję i przyszły wzrost liczby małych bloków specjalnego vdev.
Przed przeniesieniem metadanych produkcyjnych przetestuj procedury przywracania i wymiany.

Wybór nośnika w obrębie poziomu SSD nadal ma znaczenie, ale dopiero wtedy, gdy architektura jest prawidłowa. Porównanie firmy ZimaSpace dotyczące zachowania dysków SSD SATA i NVMe w obciążeniach NAS pomaga wybrać urządzenie po zrozumieniu presji na pamięć RAM, rozmieszczenia metadanych i ograniczeń sieci.

Która modernizacja powinna być pierwsza?

Najpierw dodaj więcej pamięci RAM, gdy

Dodaj pamięć RAM, gdy aplikacje wypierają dane z ARC, system korzysta ze stronicowania, często używane metadane są regularnie usuwane z pamięci lub większa pamięć podręczna poprawia wykonywanie zadania. Zostaw wystarczającą ilość pamięci dla systemu operacyjnego i usług, zamiast bezrefleksyjnie przydzielać każdy dodatkowy gigabajt do ARC.

Najpierw dodaj lustrzany poziom metadanych SSD, gdy

Wybierz specjalny vdev, gdy serwer ma już wystarczającą ilość pamięci, ale przeglądanie zimnych metadanych, operacje na migawkach i małe losowe wyszukiwania nadal są ograniczone przez dyski HDD. Użyj lustrzanych dysków SSD o wysokiej wytrzymałości, zachowaj wolne miejsce i traktuj te urządzenia jako niezastępowalnych członków puli.

Kiedy zamiast tego zbudować osobną pulę SSD

Użyj niezależnej puli SSD, gdy gorące dane są wyraźnie ograniczone — na przykład dyski maszyn wirtualnych, bazy danych, kontenery, indeksy lub bieżące projekty — i powinny mieć własną politykę tworzenia kopii zapasowych oraz migracji. Dzięki temu metadane każdej puli nie będą zależne od tej samej klasy specjalnej.

Najczęściej zadawane pytania

Czy pełny ARC oznacza, że NAS potrzebuje więcej pamięci RAM?

Nie. ARC jest zaprojektowany do wykorzystywania dostępnej pamięci. Zamiast uznawać wysokie wykorzystanie za awarię, sprawdź szkodliwe eksmisje, niskie współczynniki trafień dla danego obciążenia, presję odzyskiwania pamięci, stronicowanie oraz rywalizację aplikacji o pamięć.

Czy można dodać specjalny vdev bez redundancji?

Można go tak skonfigurować, ale tworzy to krytyczny punkt awarii związany z pojedynczym urządzeniem przechowującym metadane puli. Pula produkcyjna powinna chronić i monitorować klasę specjalną co najmniej tak starannie jak swoje podstawowe vdevy danych.

Czy większa ilość pamięci RAM może sprawić, że skanowanie zimnych metadanych będzie zawsze szybkie?

Tylko wtedy, gdy użyteczne metadane mogą pozostać w pamięci, a obciążenie odwołuje się do nich ponownie przed ich usunięciem. Ponowne uruchomienia, bardzo duże przestrzenie nazw, konkurujące aplikacje i skanowania jednorazowe nadal mogą wymuszać odczyty z dysków HDD, nawet na serwerze z dużą ilością pamięci.

Ostateczny werdykt

Najpierw dodaj pamięć RAM, gdy problemem jest pojemność ARC lub rywalizacja o pamięć. Dodaj lustrzany specjalny vdev SSD, gdy pamięci jest już wystarczająco dużo, ale nietrafienia zimnych metadanych nadal powodują opóźnienia wyszukiwania na dyskach HDD. Użyj osobnej puli SSD, gdy znane są gorące zbiory danych i powinny mieć własną granicę odzyskiwania. Najlepsza modernizacja wynika ze zmierzonej ścieżki nietrafień, a nie z najbardziej znajomej etykiety pamięci podręcznej.