ZFS ARC-optimering: Tak, gränser och vad man ska mäta

ZFS tar som standard tyst ungefär hälften av systemets RAM-minne för sin läscache, och på fel typ av server innebär det swap-aktivitet, OOM-avstängningar eller att en databas konkurrerar med filsystemet om minnet. ZFS ARC-justering handlar om att bestämma hur mycket av det RAM-minnet som ARC faktiskt får behålla, och vad du avstår från för att sätta gränsen. Det här inlägget behandlar hur ARC använder minne, vad du bör mäta innan du gör några ändringar, de få inställningar som är värda att ändra samt rimliga utgångspunkter för filservrar, hypervisorer, databaser och säkerhetskopieringsmål. För information om ZFS-snapshots, se vår guide till ZFS-snapshots.

Mät ARC innan du justerar något

Ändra inte en enda inställning förrän du har basvärden från en normal period med hög belastning. Ögonblicksbilder från lugna perioder leder dig i fel riktning. Nattliga säkerhetskopieringar, veckorapporter och batchjobb är vanligtvis de tillfällen då ARC-beteendet blir intressant, så samla in data under flera dagar.

Tre verktyg täcker det mesta av vad du behöver:

• arcstat 1 ger en rullande realtidsvy av hit- och miss-räknare, efterfrågan kontra prefetch-aktivitet samt aktuell ARC-storlek. Använd det under belastningstester och säkerhetskopieringsfönster.
• arc_summary skriver ut en enskild ögonblicksbild: ARC-storlek och mål, fördelningen mellan MFU och MRU, metadataproportioner samt aktiva inställningsparametrar. Kör arc_summary -s arc endast för ARC-avsnittet.
• Råa räknare finns /proc/spl/kstat/zfs/arcstats på Linux och under kstat.zfs.misc och vfs.zfs sysctl-träd på FreeBSD. Hämta dessa från övervakningen istället för att analysera formaterad utdata.

De mätvärden som bör registreras innan någon ändring görs:

Det finns två saker som folk ofta missförstår här. Håll koll på tillgängligt minne, inte ledigt minne; Linux rapporterar gärna lågt ledigt RAM-minne som ett normaltillstånd, och det är i sig inget problem. Den signal som spelar roll är tillgängligt minne nära noll i kombination med ihållande swap-aktivitet (introduktionen till Linux minneshantering förklarar varför). Och betrakta träfffrekvensen som en trend, inte ett mål. En träfffrekvens på 99 % på en maskin som swappar är ett misslyckande i optimeringen, inte en framgång.

De fyra viktiga ARC-inställningarna

Det mesta av produktionsjusteringen handlar om fyra inställningar. Anpassa inställningen efter det tryck du faktiskt mätte i baslinjen. Aktiviteten på Swap pekar på zfs_arc_max. Återvinn churn som hela tiden rensar en varm cache pekar på zfs_arc_min. Långsamma kataloggenomgångar pekar på metadatagränsen.

Börja med den minsta ändringen som åtgärdar den belastning du kan se. För zfs_arc_max beror det rätta taket på arbetsbelastningen (behandlas i nästa avsnitt). För zfs_arc_minär en nedre gräns på 25–50 % av zfs_arc_max är en rimlig utgångspunkt om du överhuvudtaget behöver en. För metadata ger de senaste standardinställningarna i OpenZFS redan metadata 75 % av ARC via zfs_arc_meta_limit_percent, vilket är generöst för de flesta arbetsbelastningar; ändra detta endast när metadata-missar är tydligt synliga i arcstat.

Tillämpa ändringar på Linux och FreeBSD

På Linux testar du en ändring under körning genom att skriva till sysfs-parameterfilen. Ingen omstart behövs:

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

Det ställer in zfs_arc_max till 16 GiB omedelbart. För att ändringen ska bestå efter en omstart lägger du till den i /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

I FreeBSD använder körningsändringar sysctl:

sysctl vfs.zfs.arc_max=17179869184

Behåll samma värde i /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Ändra en inställning i taget, i små steg på cirka 10 % av det totala RAM-minnet. Håll koll på problemfönstret. Behåll ändringen endast om swap förblir noll och latensen är stabil. Gör ändringen permanent först efter att körningstestet har godkänts.

Anpassa ARC efter arbetsbelastning

Det totala RAM-minnet är fel utgångspunkt. Dimensioneringen av ARC bör baseras på arbetsbelastningsmixen på servern.

En VM-värd måste dela minne med sina gäster, så en gräns på 30–40 % är ett säkert standardvärde och 50 % är redan för högt för de flesta konfigurationer. Databaser som PostgreSQL och MySQL hanterar sina egna buffertcacher, så du reserverar minne för motorn först och låter ARC ta det som blir över. Backupmål drar nytta av primarycache=metadata eftersom de data som läses sällan behövs igen, och man vill inte att en nattlig säkerhetskopiering ska gå igenom hela poolen och tömma resten av cachen efterhand. För alla arbetsbelastningar gäller att om swap-aktivitet förekommer medan ARC är låst vid zfs_arc_max att taket är för högt; den regeln gäller alltid.

Att diagnostisera problem och veta när man ska sluta

Ett för litet ARC visar sig som höga läs-IOPS, låga träfffrekvenser och långsam katalogbläddring samtidigt som systemet fortfarande har ledigt RAM-minne. Ett för stort ARC är mindre uppenbart. Träfffrekvensen ser bra ut, men servern börjar svappa, belastningsgenomsnittet stiger, processer blockeras i D medan kärnan återvinner ARC-sidor vid behov, och i värsta fall börjar OOM-killer välja offer. Cachen ser frisk ut och servern känns usel.

Metadatapress uppstår när demand_metadata_bytes ligger betydligt högre än demand_data_bytes i arc_summary. Det är då metadata konkurrerar med data om utrymme, och det är värt att höja gränsen för metadataandelen.

Jämför det du ser med den första inställningen som ska kontrolleras:

L2ARC är inte gratis. Indexet för L2ARC-poster finns i primär ARC, och om den extra belastningen överstiger ungefär en tredjedel av den totala ARC-kapaciteten gör den sekundära cachen mer skada än nytta. Använd L2ARC endast när arbetsuppsättningen är större än RAM-minnet men fortfarande ryms på en snabb NVMe-enhet, och endast när träfffrekvensen i den primära ARC-cachen redan är god.

Rätt tidpunkt att sluta med finjusteringen är när latensen är stabil, swap-användningen förblir noll under samma belastningsperiod som orsakade det ursprungliga problemet, och ytterligare ändringar inte längre förbättrar något. En hög träfffrekvens betyder ingenting om servern swappar. När du har passerat den punkten ska du sluta justera inställningarna och endast se över dem igen om samma problem återkommer under samma arbetsbelastning.

Om du behöver en server med tillräckligt med RAM-minne för att köra ZFS ordentligt utan att behöva konkurrera om minnet med dina virtuella maskiner eller databaser (det är värt att först läsa om hur mycket RAM-minne du faktiskt behöver), ta en titt på FDC:s dedikerade servrar.