Ottimizzazione di ZFS ARC: soglie, limiti e cosa misurare

Per impostazione predefinita, ZFS occuperà silenziosamente circa metà della RAM di sistema per la propria cache di lettura e, su un server non adatto, ciò comporta attività di swap, terminazioni OOM o un database in competizione con il filesystem per la memoria. L’ottimizzazione dell’ARC di ZFS consiste nel decidere quanta di quella RAM l’ARC sia effettivamente autorizzato a mantenere e a cosa si rinuncia per impostare il limite. Questo articolo illustra come l’ARC utilizza la memoria, cosa misurare prima di intervenire, i pochi parametri che vale la pena modificare e i punti di partenza consigliati per file server, hypervisor, database e destinazioni di backup. Per quanto riguarda gli snapshot di ZFS, consultate la nostra guida agli snapshot ZFS.

Misurate l’ARC prima di ottimizzare qualsiasi parametro

Non modificare alcun parametro regolabile finché non si dispone dei valori di riferimento relativi a un normale periodo di traffico intenso. Le istantanee relative a periodi di traffico ridotto potrebbero indurre in errore. I backup notturni, i report settimanali e i processi batch sono solitamente i contesti in cui il comportamento dell’ARC diventa interessante, pertanto è necessario acquisire i dati nell’arco di diversi giorni.

Tre strumenti coprono la maggior parte delle vostre esigenze:

• arcstat 1 fornisce una visualizzazione in tempo reale a scorrimento dei contatori di hit e miss, dell’attività di richiesta rispetto a quella di prefetch e delle dimensioni attuali dell’ARC. Utilizzatelo durante i test di carico e le finestre di backup.
• arc_summary stampa una singola istantanea: dimensione e target dell’ARC, ripartizione MFU/MRU, rapporti dei metadati e parametri di ottimizzazione attivi. Eseguite arc_summary -s arc solo per la sezione ARC.
• I contatori grezzi si trovano /proc/spl/kstat/zfs/arcstats su Linux e sotto il kstat.zfs.misc e vfs.zfs alberi sysctl su FreeBSD. È preferibile estrarli dal sistema di monitoraggio piuttosto che analizzare l'output formattato.

I contatori che vale la pena registrare prima di qualsiasi modifica:

Ci sono due cose che spesso vengono fraintese in questo contesto. Occorre monitorare la memoria disponibile, non quella libera; Linux segnala tranquillamente una RAM libera bassa come stato stabile e questo di per sé non è un problema. Il segnale che conta è una memoria disponibile vicina allo zero, combinata con un’attività di swap prolungata (la guida introduttiva alla gestione della memoria in Linux spiega il perché). Inoltre, considerate il rapporto di hit come una tendenza, non come un obiettivo. Un rapporto di hit del 99% su una macchina che sta effettuando lo swap è un fallimento nell’ottimizzazione, non un successo.

I quattro parametri di regolazione ARC che contano

La maggior parte dell’ottimizzazione in produzione si riduce a quattro impostazioni. Adatta l’impostazione alla pressione effettivamente misurata nella linea di base. L’attività di swap indica zfs_arc_max. Il recupero del churn che continua a svuotare una cache attiva indica zfs_arc_min. I percorsi lenti nelle directory indicano il limite dei metadati.

Inizia con la modifica più piccola che risolva il problema che riesci a individuare. Per zfs_arc_max, il limite massimo corretto dipende dal carico di lavoro (argomento trattato nella sezione successiva). Per zfs_arc_min, un limite minimo compreso tra il 25% e il 50% di zfs_arc_max è un punto di partenza ragionevole, se proprio ne serve uno. Per i metadati, le recenti impostazioni predefinite di OpenZFS assegnano già ai metadati il 75% dell’ARC tramite zfs_arc_meta_limit_percent, il che è più che sufficiente per la maggior parte dei carichi di lavoro; intervenire su questo valore solo quando le mancate individuazioni dei metadati sono chiaramente visibili in arcstat.

Applicazione delle modifiche su Linux e FreeBSD

Su Linux, è possibile testare una modifica durante l’esecuzione scrivendo nel file dei parametri sysfs. Non è necessario riavviare il sistema:

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

Questo imposta zfs_arc_max a 16 GiB immediatamente. Per far sì che la modifica sopravviva al riavvio, aggiungerla a /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

Su FreeBSD, le modifiche in fase di esecuzione utilizzano sysctl:

sysctl vfs.zfs.arc_max=17179869184

Per mantenere lo stesso valore in /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Modifica un’impostazione alla volta, con piccoli incrementi pari a circa il 10% della RAM totale. Tieni d’occhio la finestra dei problemi. Mantieni la modifica solo se lo swap rimane a zero e la latenza è stabile. Rendi permanente l’impostazione solo dopo che il test in fase di esecuzione è andato a buon fine.

Ottimizzazione dell’ARC in base al carico di lavoro

La RAM totale non è il punto di partenza corretto. Il dimensionamento dell’ARC deve seguire la composizione del carico di lavoro sul dispositivo.

Un host VM deve condividere la memoria con i propri guest, quindi un limite dal 30% al 40% è un valore predefinito sicuro e il 50% è già troppo alto nella maggior parte delle configurazioni. Database come PostgreSQL e MySQL gestiscono autonomamente le proprie cache di buffer, quindi è necessario riservare prima la memoria per il motore e lasciare ad ARC ciò che rimane. Le destinazioni di backup traggono vantaggio da primarycache=metadata poiché i dati letti raramente vengono riutilizzati e non è auspicabile che un backup notturno scorra l’intero pool svuotando il resto della cache man mano che procede. Per ogni carico di lavoro, l’attività di swap mentre l’ARC è bloccato a zfs_arc_max indica che il limite è troppo alto; questa regola non cambia.

Diagnosticare i problemi e sapere quando fermarsi

Un ARC sottodimensionato si manifesta con un elevato numero di IOPS in lettura, bassi tassi di hit delle richieste e navigazione lenta nelle directory, mentre il sistema dispone ancora di RAM libera. Un ARC sovradimensionato è meno evidente. Il tasso di hit sembra a posto, ma il sistema inizia a ricorrere allo swapping, le medie di carico salgono, i processi rimangono bloccati in D stato mentre il kernel recupera le pagine dell’ARC su richiesta e, nel peggiore dei casi, l’OOM killer inizia a scegliere le vittime. La cache sembra in buone condizioni, ma il server funziona malissimo.

La pressione sui metadati si manifesta quando demand_metadata_bytes è molto più alta rispetto a demand_data_bytes in arc_summary. È in quel momento che i metadati competono con i dati per lo spazio, e vale la pena aumentare il limite percentuale dei metadati.

Confronta ciò che osservi con la prima impostazione da verificare:

L2ARC non è gratuito. L'indice delle voci L2ARC risiede nell'ARC primario e, se tale overhead supera circa un terzo della capacità totale dell'ARC, la cache secondaria fa più male che bene. Ricorrere a L2ARC solo quando il working set è più grande della RAM ma rientra comunque in un dispositivo NVMe veloce, e solo quando il rapporto di hit dell’ARC primario è già soddisfacente.

Il momento giusto per interrompere l’ottimizzazione è quando la latenza rimane stabile, lo swap rimane a zero durante lo stesso periodo di picco di carico che ha causato il problema originale e ulteriori modifiche non apportano più alcun miglioramento. Un rapporto di hit elevato non significa nulla se il server sta effettuando lo swap. Superato quel punto, smettete di modificare le impostazioni e rivedetele solo se lo stesso problema si ripresenta con lo stesso carico di lavoro.

Se avete bisogno di un server con margine di RAM sufficiente per eseguire correttamente ZFS senza dover competere con le vostre VM o i vostri database per la memoria (vale la pena leggere prima "Quanta RAM vi serve effettivamente?"), date un’occhiata ai server dedicati FDC.