ZFS ARC-afstemming: limieten, grenzen en wat je moet meten

ZFS neemt standaard stilletjes ongeveer de helft van uw systeem-RAM in beslag voor zijn leescache, en op het verkeerde type server leidt dat tot swap-activiteit, OOM-kills of een database die met het bestandssysteem concurreert om geheugen. Bij het afstemmen van de ZFS ARC gaat het erom te bepalen hoeveel van dat RAM de ARC daadwerkelijk mag behouden, en wat u opgeeft om de limiet in te stellen. Dit artikel behandelt hoe de ARC geheugen gebruikt, wat je moet meten voordat je iets aanpast, de paar instellingen die het waard zijn om te wijzigen, en verstandige uitgangspunten voor bestandsservers, hypervisors, databases en back-updoelen. Voor de snapshot-kant van ZFS, zie onze gids over ZFS-snapshots.

Meet ARC voordat u iets aanpast

Verander geen enkele instelling voordat je basisgegevens hebt van een normale drukke periode. Momentopnames uit rustige periodes leiden je de verkeerde kant op. Nachtelijke back-ups, wekelijkse rapporten en batchtaken zijn meestal de momenten waarop het ARC-gedrag interessant wordt, dus leg gegevens vast over meerdere dagen.

Drie tools dekken het grootste deel van wat je nodig hebt:

• arcstat 1 geeft een live scrollend overzicht van hit- en miss-tellers, vraag versus prefetch-activiteit en de huidige ARC-grootte. Gebruik deze tijdens belastingstests en back-upvensters.
• arc_summary geeft een enkele momentopname weer: ARC-grootte en -doel, de MFU/MRU-verdeling, metadataverhoudingen en actieve instelbare parameters. Voer arc_summary -s arc alleen voor het ARC-gedeelte.
• Ruwe tellers zijn beschikbaar /proc/spl/kstat/zfs/arcstats op Linux en onder de kstat.zfs.misc en vfs.zfs sysctl-structuren op FreeBSD. Haal deze uit de monitoring in plaats van opgemaakte uitvoer te parseren.

De tellers die vóór elke wijziging moeten worden vastgelegd:

Twee dingen die mensen hier vaak verkeerd begrijpen. Let op het beschikbare geheugen, niet op het vrije geheugen; Linux rapporteert zonder problemen een laag vrij RAM-geheugen als een stabiele toestand en dat is op zich geen probleem. Het signaal dat ertoe doet, is beschikbaar geheugen dat bijna nul is in combinatie met aanhoudende swap-activiteit (in de inleiding tot geheugenbeheer in Linux wordt uitgelegd waarom). En beschouw de hitratio als een trend, niet als een streefwaarde. Een hitratio van 99% op een systeem dat swapt, is een mislukking in de afstemming, geen succes.

De vier belangrijke ARC-instellingen

Het afstemmen in de productieomgeving komt grotendeels neer op vier instellingen. Stem de instelling af op de druk die je daadwerkelijk in de baseline hebt gemeten. Swap-activiteit wijst op zfs_arc_max. Het terugwinnen van churn die een ‘hot cache’ blijft leegmaken, wijst op zfs_arc_min. Trage directory-doorlopen wijzen op de metadata-limiet.

Begin met de kleinste wijziging die de druk die je waarneemt verhelpt. Voor zfs_arc_max, hangt de juiste bovengrens af van de werklast (wordt in de volgende paragraaf behandeld). Voor zfs_arc_minis een ondergrens van 25% tot 50% van zfs_arc_max is een redelijk uitgangspunt, mocht je er al een nodig hebben. Voor metadata geven de recente standaardinstellingen van OpenZFS al 75% van ARC aan metadata via zfs_arc_meta_limit_percent, wat voor de meeste werkbelastingen ruim voldoende is; pas dit alleen aan als er duidelijk metadata-missers zichtbaar zijn in arcstat.

Wijzigingen doorvoeren op Linux en FreeBSD

Test onder Linux een wijziging tijdens het draaien door naar het sysfs-parameterbestand te schrijven. Een herstart is niet nodig:

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

Dat stelt zfs_arc_max onmiddellijk ingesteld op 16 GiB. Om ervoor te zorgen dat de wijziging na een herstart behouden blijft, voeg je deze toe aan /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

Op FreeBSD gebruiken wijzigingen tijdens de uitvoering sysctl:

sysctl vfs.zfs.arc_max=17179869184

Zorg ervoor dat dezelfde waarde blijft bestaan in /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Wijzig één instelling tegelijk, in kleine stappen van ongeveer 10% van het totale RAM-geheugen. Houd het probleemvenster in de gaten. Handhaaf de wijziging alleen als het swapgeheugen op nul blijft en de latentie stabiel is. Maak de wijziging pas permanent nadat de test tijdens het gebruik is geslaagd.

ARC afstemmen op de werklast

Het totale RAM-geheugen is niet het juiste uitgangspunt. De ARC-grootte moet worden afgestemd op de mix van workloads op de server.

Een VM-host moet geheugen delen met zijn gasten, dus een limiet van 30% tot 40% is een veilige standaardinstelling en 50% is bij de meeste opstellingen al te hoog. Databases zoals PostgreSQL en MySQL beheren hun eigen buffercaches, dus reserveer je eerst geheugen voor de engine en laat je ARC de rest gebruiken. Back-updoelen profiteren hiervan primarycache=metadata omdat de gelezen gegevens zelden opnieuw nodig zijn, en je niet wilt dat een nachtelijke back-up de hele pool doorloopt en daarbij de rest van de cache leegmaakt. Voor elke workload geldt dat swap-activiteit terwijl ARC vastgezet is op zfs_arc_max betekent dat de limiet te hoog is; die regel verandert niet.

Problemen diagnosticeren en weten wanneer je moet stoppen

Een te kleine ARC uit zich in hoge lees-IOPS, lage hitratio’s bij verzoeken en traag bladeren door mappen, terwijl het systeem nog steeds over vrij RAM beschikt. Een te grote ARC is minder voor de hand liggend. De hitratio ziet er prima uit, maar de server begint te swappen, de load averages stijgen, processen blokkeren in D terwijl de kernel ARC-pagina’s op verzoek vrijmaakt, en in het ergste geval begint de OOM-killer slachtoffers te selecteren. De cache ziet er gezond uit, maar de server presteert slecht.

Druk op de metadata doet zich voor wanneer demand_metadata_bytes de waarde veel hoger ligt dan demand_data_bytes in arc_summary. Dat is het moment waarop metadata met gegevens om ruimte strijdt, en het de moeite waard is om de limiet voor het metadata-percentage te verhogen.

Vergelijk wat je ziet met de eerste instelling die je moet controleren:

L2ARC is niet gratis. De index voor L2ARC-vermeldingen bevindt zich in de primaire ARC, en als die overhead oploopt tot meer dan ongeveer een derde van de totale ARC-capaciteit, doet de secundaire cache meer kwaad dan goed. Gebruik L2ARC alleen wanneer de werkverzameling groter is dan het RAM-geheugen maar nog steeds op een snel NVMe-apparaat past, en alleen wanneer de hitratio van de primaire ARC al gezond is.

Het juiste moment om te stoppen met afstemmen is wanneer de latentie stabiel is, het swapgebruik op nul blijft tijdens hetzelfde drukke tijdsvenster dat het oorspronkelijke probleem veroorzaakte, en verdere aanpassingen niets meer verbeteren. Een hoge hitratio betekent niets als de server aan het swappen is. Pas daarna moet u stoppen met het aanpassen van instellingen en deze alleen opnieuw bekijken als hetzelfde probleem terugkeert bij dezelfde werklast.

Als u een server nodig hebt met voldoende RAM-ruimte om ZFS goed te laten draaien zonder te hoeven strijden met uw VM’s of databases om geheugen (het is de moeite waard om eerst te lezen hoeveel RAM u daadwerkelijk nodig hebt), kijk dan eens naar de dedicated servers van FDC.