Optimizarea ZFS ARC: plafoane, limite și ce trebuie măsurat

În mod implicit, ZFS va ocupa discret aproximativ jumătate din memoria RAM a sistemului pentru cache-ul de citire, iar pe un tip de server nepotrivit, acest lucru înseamnă activitate de swap, terminarea proceselor din cauza epuizării memoriei (OOM) sau o bază de date care concurează cu sistemul de fișiere pentru memorie. Optimizarea ARC a ZFS înseamnă să decideți cât din acea memorie RAM are ARC permisiunea efectivă să păstreze și la ce renunțați pentru a seta limita. Acest articol prezintă modul în care ARC utilizează memoria, ce trebuie măsurat înainte de a interveni, câteva setări care merită modificate și puncte de pornire recomandate pentru servere de fișiere, hipervizori, baze de date și destinații de backup. Pentru informații despre instantaneele ZFS, consultați ghidul nostru privind instantaneele ZFS.

Măsurați ARC înainte de a regla orice

Nu modificați niciun parametru reglabil până când nu aveți valorile de referință dintr-o perioadă normală de trafic intens. Instantaneele din perioadele de trafic redus vă vor îndruma în direcția greșită. Backup-urile nocturne, rapoartele săptămânale și sarcinile de tip batch sunt, de obicei, momentele în care comportamentul ARC devine interesant, așa că capturați date pe parcursul mai multor zile.

Trei instrumente acoperă cea mai mare parte a ceea ce aveți nevoie:

• arcstat 1 oferă o vizualizare în timp real, cu derulare, a contoarelor de acces reușite și eșuate, a activității de cerere față de cea de preluare anticipată și a dimensiunii curente a ARC. Utilizați-l în timpul testelor de încărcare și al ferestrelor de backup.
• arc_summary imprimă o singură instantanee: dimensiunea și ținta ARC, împărțirea MFU/MRU, raporturile de metadate și parametrii de reglare activi. Rulați arc_summary -s arc doar pentru secțiunea ARC.
• Contoarele brute se găsesc /proc/spl/kstat/zfs/arcstats pe Linux și sub kstat.zfs.misc și vfs.zfs arborii sysctl pe FreeBSD. Extrageți-le din sistemul de monitorizare, în loc să analizați ieșirea formatată.

Contorii care merită înregistrați înainte de orice modificare:

Două greșeli frecvente în acest context. Urmăriți memoria disponibilă, nu memoria liberă; Linux raportează fără probleme un nivel scăzut de RAM liber ca stare normală, iar acest lucru în sine nu reprezintă o problemă. Semnalul care contează este memoria disponibilă aproape de zero, combinată cu o activitate susținută de swap (ghidul de bază privind gestionarea memoriei în Linux explică de ce). Și tratați rata de acces reușit ca pe o tendință, nu ca pe un obiectiv. O rată de acces reușit de 99% pe un sistem care utilizează swap reprezintă un eșec al optimizării, nu un succes.

Cele patru parametri ARC care contează

Cea mai mare parte a reglajelor de producție se reduce la patru setări. Potriviți setarea cu presiunea pe care ați măsurat-o efectiv în linia de bază. Activitatea de swap indică zfs_arc_max. Recuperarea pierderilor de clienți care șterg în mod repetat un cache activ indică zfs_arc_min. Parcurgerea lentă a directoarelor indică limita de metadate.

Începeți cu cea mai mică modificare care rezolvă presiunea pe care o observați. Pentru zfs_arc_max, limita superioară corectă depinde de volumul de lucru (subiect abordat în secțiunea următoare). Pentru zfs_arc_min, o valoare minimă de 25% până la 50% din zfs_arc_max este un punct de plecare rezonabil, dacă aveți nevoie de unul. Pentru metadate, valorile implicite recente ale OpenZFS alocă deja metadatelor 75% din ARC prin zfs_arc_meta_limit_percent, ceea ce este suficient pentru majoritatea sarcinilor de lucru; modificați această setare doar atunci când lipsurile de metadate sunt clar vizibile în arcstat.

Aplicarea modificărilor pe Linux și FreeBSD

Pe Linux, testați o modificare în timpul rulării scriind în fișierul de parametri sysfs. Nu este necesară repornirea:

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

Aceasta setează zfs_arc_max imediat la 16 GiB. Pentru ca modificarea să se mențină după repornire, adăugați-o la /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

Pe FreeBSD, modificările în timpul rulării utilizează sysctl:

sysctl vfs.zfs.arc_max=17179869184

Persistați aceeași valoare în /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Modificați câte o setare pe rând, în pași mici de aproximativ 10% din memoria RAM totală. Urmăriți fereastra de monitorizare a problemelor. Păstrați modificarea doar dacă swap-ul rămâne la zero și latența este stabilă. Persistați modificarea doar după ce testul în timpul rulării este reușit.

Dimensionarea ARC în funcție de încărcarea de lucru

Memoria RAM totală nu este un punct de plecare adecvat. Dimensionarea ARC trebuie să țină cont de combinația de sarcini de lucru de pe server.

Un gazdă VM trebuie să împartă memoria cu oaspeții săi, așa că o limită de 30% până la 40% este o valoare implicită sigură, iar 50% este deja prea mare pentru majoritatea configurațiilor. Bazele de date precum PostgreSQL și MySQL își gestionează propriile cache-uri de buffer, așa că rezervați mai întâi memoria pentru motor și lăsați ARC să folosească ce rămâne. Țintele de backup beneficiază de primarycache=metadata faptul că datele citite sunt rareori necesare din nou, iar dumneavoastră nu doriți ca o copie de rezervă nocturnă să parcurgă întregul pool și să golească restul cache-ului pe măsură ce avansează. Pentru orice sarcină de lucru, activitatea de swap în timp ce ARC este fixat la zfs_arc_max înseamnă că limita maximă este prea mare; această regulă nu se schimbă.

Diagnosticarea problemelor și cunoașterea momentului în care trebuie să vă opriți

Un ARC subdimensionat se manifestă prin IOPS de citire ridicate, rate de acces la cerere scăzute și navigare lentă în directoare, în timp ce sistemul încă dispune de memorie RAM liberă. Un ARC supradimensionat este mai puțin evident. Rata de acces pare în regulă, dar sistemul începe să utilizeze swap-ul, mediile de încărcare cresc, procesele se blochează în D în timp ce kernelul recuperează paginile ARC la cerere, iar în cel mai rău caz, OOM killer începe să aleagă victimele. Cache-ul pare sănătos, iar serverul funcționează extrem de prost.

Presiunea asupra metadatelor se manifestă atunci când demand_metadata_bytes este mult mai mare decât demand_data_bytes în arc_summary. Atunci metadatele se luptă cu datele pentru spațiu, iar limita procentuală a metadatelor merită mărită.

Corelați ceea ce observați cu prima setare pe care trebuie să o verificați:

L2ARC nu este gratuit. Indexul pentru intrările L2ARC se află în ARC-ul primar, iar dacă această suprasolicitare depășește aproximativ o treime din capacitatea totală a ARC-ului, cache-ul secundar face mai mult rău decât bine. Apelați la L2ARC numai atunci când setul de lucru este mai mare decât memoria RAM, dar încă încape pe un dispozitiv NVMe rapid, și numai atunci când rata de accesare a ARC-ului primar este deja satisfăcătoare.

Momentul potrivit pentru a opri optimizarea este atunci când latența rămâne constantă, swap-ul rămâne la zero pe durata aceleiași perioade de încărcare care a cauzat problema inițială, iar modificările suplimentare nu mai aduc nicio îmbunătățire. O rată de acces reușit ridicată nu înseamnă nimic dacă serverul folosește swap-ul. După acest punct, opriți ajustarea setărilor și revizuiți-le doar dacă aceeași problemă reapare în condițiile aceleiași sarcini de lucru.

Dacă aveți nevoie de un server cu suficient spațiu liber în memoria RAM pentru a rula ZFS corespunzător, fără a intra în conflict cu mașinile virtuale sau bazele de date pentru memorie (merită să citiți mai întâi articolul „De câtă memorie RAM aveți nevoie de fapt?”), aruncați o privire la serverele dedicate FDC.