Perché l'ARC di ZFS si riduce quando l'IA locale utilizza memoria host bloccata?

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

ZFS ARC si riduce durante l'uso di memoria host bloccata perché i buffer di trasferimento AI non recuperabili aumentano la pressione sulla memoria che il kernel può recuperare, inclusa la cache del filesystem.

I runtime GPU bloccano le pagine host affinché i dispositivi possano trasferire dati senza che tali pagine vengano spostate o trasferite nello swap durante l'operazione. Questo migliora la prevedibilità del DMA, ma le allocazioni bloccate sono difficili da recuperare quando la RAM disponibile diminuisce. Linux attiva il recupero della memoria e gli shrinker, mentre ZFS risponde espellendo i blocchi memorizzati nella cache o riducendo il proprio obiettivo ARC, lasciando più memoria alle allocazioni che non possono essere liberate.

Le pagine bloccate modificano la memoria che il kernel può recuperare

Le normali pagine anonime possono essere trasferite nello swap e le pagine pulite della cache dei file possono essere scartate. Le pagine bloccate a lungo termine rimangono residenti perché un dispositivo o un driver dipende dalla loro mappatura fisica, riducendo il pool flessibile disponibile per soddisfare le nuove allocazioni.

La documentazione Linux relativa al blocco a lungo termine delle pagine distingue il blocco a lungo termine delle pagine dai riferimenti ordinari e spiega perché gli utenti DMA debbano contrassegnare correttamente le pagine. Il meccanismo rende la memoria bloccata qualitativamente diversa da un'allocazione di processo che il kernel può spostare o recuperare facilmente.

I framework AI usano buffer di staging bloccati per velocizzare le copie da host a dispositivo, le code dei dataloader e l'offload. Più worker o code di prefetch sovradimensionate possono mantenere bloccata una quantità di memoria host molto maggiore di quella suggerita da un singolo batch visibile. Questa distinzione rimane evidente durante i successivi test domestici.

ARC è progettata per essere un'ampia risorsa recuperabile

La Adaptive Replacement Cache conserva i blocchi ZFS usati di recente e frequentemente per evitare letture dallo storage. Su Linux partecipa alla gestione della pressione sulla memoria e può ridurre le proprie dimensioni residenti quando il sistema necessita di pagine altrove. Il risultato intermedio deve rimanere ispezionabile prima che l'automazione proceda.

La documentazione OpenZFS relativa a dimensioni e recupero di ARC descrive i controlli delle dimensioni di ARC e i parametri regolabili relativi al recupero. Un limite massimo configurato è un tetto, non una garanzia che i dati memorizzati nella cache rimangano residenti sotto pressione. Questo limite deve essere misurato separatamente in condizioni operative realistiche.

Quando i buffer bloccati aumentano, l'espulsione di ARC può essere la risposta corretta, non una perdita di memoria. La conseguenza si manifesta in seguito con rapporti di riscontri nella cache più bassi, più letture dal disco e accesso ai file più lento dopo la fine del processo AI, finché la cache non si riscalda nuovamente.

La memoria unificata e le metriche dei container possono nascondere la competizione

Su una GPU integrata, i tensori del modello e la cache del filesystem utilizzano la stessa RAM fisica, anche quando i dashboard indicano l'utilizzo in modo diverso. Su una GPU discreta, lo staging sull'host rimane separato dalla VRAM, ma compete comunque con ARC sul server.

L'implementazione OpenZFS dello shrinker di ARC di Linux registra il comportamento di recupero di ARC con la gestione della memoria del kernel. Le prove a livello di codice aiutano a distinguere la riduzione intenzionale della cache da un'applicazione che ordina direttamente a ZFS di scartare i blocchi. La conseguenza pratica emerge quando diverse fonti competono per un contesto limitato.

Il limite dell'analisi consiste nell'ipotizzare memoria bloccata ogni volta che ARC diminuisce. Una scansione di file di grandi dimensioni, limiti ARC espliciti, pressione sui metadati, recupero da cgroup, crescita delle macchine virtuali o il normale comportamento adattivo possono produrre lo stesso grafico. Conferma il numero di pagine bloccate e la tempistica delle allocazioni.

-15% OFF

Correla i byte bloccati con il recupero di ARC e i mancati riscontri nella cache

Esegui un carico di lavoro AI fisso registrando la memoria bloccata o non eliminabile, MemAvailable, le attese durante il recupero, le dimensioni e l'obiettivo di ARC, il rapporto di riscontri di ARC, le letture ZFS, le dimensioni del pool di buffer bloccati, il numero di worker, le dimensioni del batch, la VRAM e la latenza delle richieste. Includi una baseline dello storage senza AI.

Usa la memoria host condivisa per separare i sintomi di CPU, memoria e storage. Ripeti con trasferimenti paginabili, una profondità di prefetch inferiore, meno worker e un pool bloccato con limiti, modificando un solo controllo per esecuzione. Questa dipendenza deve rimanere esplicita nell'interfaccia finale.

Considera il blocco causale quando la contrazione di ARC segue la crescita della memoria bloccata e si attenua con un pool più piccolo. Limita il pool se i mancati riscontri dello storage danneggiano gli altri servizi, ma conserva un blocco sufficiente a non affamare l'acceleratore; l'equilibrio corretto dipende dalla domanda NAS concorrente.

Hub Tecnologico e AI

Altro da leggere

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.