Dlaczego ARC systemu ZFS kurczy się, gdy lokalna sztuczna inteligencja korzysta z przypiętej pamięci hosta?

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.

Why Does ZFS ARC Shrink When Local AI Uses Pinned Host Memory? - Zima Store Online

Rozmiar ZFS ARC zmniejsza się podczas używania przypiętej pamięci hosta, ponieważ niemożliwe do odzyskania bufory transferowe AI zwiększają presję na pamięć, którą jądro może odzyskać, w tym na pamięć podręczną systemu plików.

Środowiska uruchomieniowe GPU przypinają strony hosta, aby urządzenia mogły przesyłać dane bez przenoszenia tych stron lub ich wymiany w trakcie operacji. Poprawia to przewidywalność DMA, ale przypisane alokacje są trudne do odzyskania, gdy ilość dostępnej pamięci RAM spada. Linux uruchamia mechanizmy odzyskiwania pamięci i shrinkery, a ZFS reaguje, usuwając buforowane bloki lub obniżając docelowy rozmiar ARC, pozostawiając więcej pamięci dla alokacji, które nie mogą jej zwolnić.

Przypięte strony zmieniają zakres pamięci, którą jądro może odzyskać

Zwykłe strony anonimowe mogą być wymieniane, a czyste strony pamięci podręcznej plików mogą zostać odrzucone. Długoterminowo przypięte strony pozostają w pamięci, ponieważ urządzenie lub sterownik zależy od ich mapowania fizycznego, co zmniejsza elastyczną pulę dostępną do obsługi nowych alokacji.

Dokumentacja Linuxa dotycząca długoterminowego przypinania stron odróżnia je od zwykłych odwołań i wyjaśnia, dlaczego użytkownicy DMA muszą odpowiednio oznaczać strony. Mechanizm ten sprawia, że przypięta pamięć różni się jakościowo od alokacji procesu, którą jądro może łatwo przenieść lub odzyskać.

Frameworki AI używają przypiętych buforów pośrednich do szybszego kopiowania danych z hosta do urządzenia, obsługi kolejek dataloadera i odciążania pamięci. Wiele procesów roboczych lub zbyt duże kolejki wstępnego pobierania mogą utrzymywać znacznie więcej przypiętej pamięci hosta, niż sugeruje pojedynczy widoczny batch. Różnica ta pozostaje widoczna podczas późniejszych testów domowych.

ARC jest z założenia dużym konsumentem pamięci możliwej do odzyskania

Adaptive Replacement Cache przechowuje ostatnio i często używane bloki ZFS, aby unikać odczytów z pamięci masowej. W systemie Linux uczestniczy w obsłudze presji pamięci i może zmniejszać swój rozmiar rezydentny, gdy system potrzebuje stron w innym miejscu. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.

Dokumentacja OpenZFS dotycząca rozmiaru ARC i odzyskiwania pamięci opisuje mechanizmy kontroli rozmiaru ARC oraz ustawienia związane z odzyskiwaniem pamięci. Skonfigurowane maksimum jest limitem, a nie obietnicą, że buforowane dane pozostaną rezydentne pod presją. Granicę tę należy mierzyć osobno w realistycznych warunkach pracy.

Gdy przypięte bufory rosną, eksmisja ARC może być właściwą reakcją, a nie wyciekiem pamięci. Konsekwencją są później niższe współczynniki trafień pamięci podręcznej, większa liczba odczytów z dysku i wolniejszy dostęp do plików po zakończeniu zadania AI, dopóki pamięć podręczna nie rozgrzeje się ponownie.

Pamięć współdzielona i metryki kontenerów mogą ukrywać rywalizację

W przypadku zintegrowanego GPU tensory modelu i pamięć podręczna systemu plików korzystają z tej samej fizycznej pamięci RAM, nawet jeśli pulpity nawigacyjne oznaczają ich użycie w różny sposób. W przypadku dedykowanego GPU pamięć hosta używana do buforowania pozostaje oddzielona od VRAM, ale nadal konkuruje z ARC na serwerze.

Implementacja OpenZFS linuxowego mechanizmu shrinkera ARC rejestruje zachowanie odzyskiwania ARC w systemowym zarządzaniu pamięcią. Dowody na poziomie kodu źródłowego pomagają odróżnić celowe zmniejszanie pamięci podręcznej od bezpośredniego nakazania ZFS przez aplikację odrzucenia bloków. Praktyczna konsekwencja pojawia się, gdy kilka źródeł konkuruje o ograniczony kontekst.

Błędem jest zakładanie, że za każdym spadkiem ARC stoi przypięta pamięć. Duże skanowanie plików, jawne limity ARC, presja na metadane, odzyskiwanie pamięci przez cgroup, rozrost maszyn wirtualnych lub zwykłe zachowanie adaptacyjne mogą wygenerować ten sam wykres. Potwierdź liczbę przypiętych stron i czas alokacji.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Skoreluj przypięte bajty z odzyskiwaniem ARC i nietrafieniami pamięci podręcznej

Uruchom stałe zadanie AI, rejestrując przypiętą lub nieusuwalną pamięć, MemAvailable, opóźnienia odzyskiwania pamięci, rozmiar i cel ARC, współczynnik trafień ARC, odczyty ZFS, rozmiar puli przypiętych buforów, liczbę procesów roboczych, rozmiar batcha, VRAM i opóźnienie żądań. Uwzględnij bazowy test pamięci masowej bez AI.

Użyj współdzielonej pamięci hosta, aby oddzielić objawy związane z procesorem, pamięcią i pamięcią masową. Powtórz testy z transferami wykorzystującymi strony możliwe do stronicowania, mniejszą głębokością wstępnego pobierania, mniejszą liczbą procesów roboczych i ograniczoną pulą przypiętej pamięci, zmieniając tylko jeden parametr sterujący w każdym przebiegu. Ta zależność powinna pozostać jawna w końcowym interfejsie.

Uznaj przypinanie za przyczynowe, gdy kurczenie się ARC odpowiada wzrostowi przypiętej pamięci i ustępuje po zmniejszeniu puli. Ogranicz pulę, jeśli nietrafienia pamięci podręcznej szkodzą innym usługom pamięci masowej, ale zachowaj wystarczające przypinanie, aby nie głodzić akceleratora; właściwa równowaga zależy od równoczesnego zapotrzebowania NAS.