Waarom krimpt de ZFS ARC wanneer lokale AI vastgezette hostgeheugenruimte gebruikt?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

ZFS ARC krimpt tijdens het gebruik van vastgezette hostgeheugenpagina's, omdat niet-reclaimbare AI-overdrachtbuffers de druk verhogen op geheugen dat de kernel kan vrijmaken, waaronder de bestandssysteemcache.

GPU-runtimes zetten hostpagina's vast zodat apparaten gegevens kunnen overdragen zonder dat die pagina's tijdens de bewerking worden verplaatst of gewisseld. Dat verbetert de voorspelbaarheid van DMA, maar vastgezette toewijzingen zijn moeilijk vrij te maken wanneer het beschikbare RAM afneemt. Linux activeert reclaim en shrinkers, waarna ZFS reageert door gecachte blokken te verwijderen of het ARC-doel te verlagen, zodat er meer geheugen beschikbaar komt voor toewijzingen die niet kunnen wijken.

Vastgezette pagina's veranderen welk geheugen de kernel kan vrijmaken

Gewone anonieme pagina's kunnen naar swap worden verplaatst en schone bestandscachepagina's kunnen worden verwijderd. Langdurig vastgezette pagina's blijven resident omdat een apparaat of stuurprogramma afhankelijk is van hun fysieke toewijzing, waardoor er minder flexibele geheugenruimte beschikbaar is voor nieuwe toewijzingen.

De Linux-documentatie over het langdurig vastzetten van pagina's maakt onderscheid tussen langdurig vastzetten en gewone verwijzingen en legt uit waarom DMA-gebruikers pagina's correct moeten markeren. Hierdoor verschilt vastgezet geheugen wezenlijk van een procestoewijzing die de kernel eenvoudig kan verplaatsen of vrijmaken.

AI-frameworks gebruiken vastgezette stagingbuffers voor snellere host-naar-apparaatkopieën, dataloader-wachtrijen en offload. Meerdere workers of te grote prefetch-wachtrijen kunnen veel meer hostgeheugen vastzetten dan één zichtbare batch doet vermoeden. Dit onderscheid blijft zichtbaar tijdens latere tests in de thuisomgeving.

ARC is van nature een grote consument van vrijmaakbaar geheugen

De Adaptive Replacement Cache bewaart recent en vaak gebruikte ZFS-blokken om leesbewerkingen vanaf de opslag te vermijden. Op Linux doet deze cache mee aan de afhandeling van geheugendruk en kan de residentiegrootte worden verkleind wanneer het systeem elders pagina's nodig heeft. Het tussenresultaat moet controleerbaar blijven voordat automatisering verdergaat.

De documentatie over ARC-grootte en reclaim van OpenZFS beschrijft instellingen voor de ARC-grootte en reclaim-gerelateerde tunables. Een geconfigureerd maximum is een bovengrens, geen belofte dat gecachte gegevens onder druk resident blijven. Die grens moet afzonderlijk worden gemeten onder realistische gebruiksomstandigheden.

Wanneer vastgezette buffers groeien, kan ARC-uitzetting de juiste reactie zijn in plaats van een lek. Het gevolg wordt later zichtbaar als lagere cache-hitratio's, meer schijflezingen en tragere bestandstoegang nadat de AI-taak is beëindigd, totdat de cache opnieuw is gevuld.

Unified memory en containermetrieken kunnen de concurrentie verbergen

Bij een geïntegreerde GPU putten modeltensoren en de bestandssysteemcache uit hetzelfde fysieke RAM, ook wanneer dashboards het gebruik verschillend labelen. Bij een discrete GPU blijft host-staging gescheiden van VRAM, maar concurreert deze nog steeds met ARC op de server.

De OpenZFS-implementatie van de Linux-ARC-shrinkerimplementatie registreert ARC-reclaimgedrag bij het kernelgeheugenbeheer. Bewijs op bronniveau helpt opzettelijk verkleinen van de cache te onderscheiden van een toepassing die ZFS rechtstreeks opdracht geeft blokken te verwijderen. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen om beperkte context concurreren.

De foutgrens is aannemen dat vastgezet geheugen de oorzaak is wanneer ARC daalt. Een grote bestandsscan, expliciete ARC-limieten, metadatadruk, reclaim binnen een cgroup, groei van virtuele machines of normaal adaptief gedrag kan dezelfde grafiek opleveren. Bevestig de aantallen vastgezette pagina's en het tijdstip van de toewijzingen.

-15% OFF
Single board computer zimaboard2

Breng vastgezette bytes in verband met ARC-reclaim en cachemissers

Voer een vaste AI-workload uit terwijl je vastgezet of niet-uitzetbaar geheugen, MemAvailable, reclaim-stalls, ARC-grootte en -doel, ARC-hitratio, ZFS-lezingen, de grootte van de pool met vastgezette buffers, het aantal workers, de batchgrootte, VRAM en de aanvraaglatentie registreert. Neem een opslagbaseline zonder AI op.

Gebruik gedeeld hostgeheugen om CPU-, geheugen- en opslagproblemen van elkaar te onderscheiden. Herhaal de test met overdrachten via paginering, een kleinere prefetch-diepte, minder workers en een begrensde pool met vastgezette buffers, waarbij je per run slechts één instelling wijzigt. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.

Beschouw het vastzetten als causaal wanneer de ARC-krimp de groei van het vastgezette geheugen volgt en afneemt bij een kleinere pool. Beperk de pool als opslagmissers andere diensten schaden, maar behoud voldoende vastgezette buffers om de accelerator niet uit te hongeren; de juiste balans hangt af van de gelijktijdige NAS-belasting.

Tech & AI HUB

Meer om te lezen

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.