Prestazioni ZFS: devo mantenere spazio libero in un pool o in un file system?

So che le prestazioni di ZFS dipendono fortemente dalla quantità di spazio libero:

Mantenere lo spazio del pool inferiore all'80% di utilizzo per mantenere le prestazioni del pool. Attualmente, le prestazioni del pool possono peggiorare quando un pool è molto pieno e i file system vengono aggiornati frequentemente, ad esempio su un server di posta occupato. I pool completi potrebbero causare una penalità per le prestazioni, ma nessun altro problema. [...] Tieni presente che anche con contenuti prevalentemente statici nell'intervallo 95-96%, le prestazioni di scrittura, lettura e ripristino potrebbero risentirne. ZFS_Best_Practices_Guide, solarisinternals.com (archive.org)

Supponiamo ora di avere un pool raidz2 di 10T che ospita un file system ZFS volume. Ora creo un file system figlio volume/teste gli do una prenotazione di 5T.

Quindi monto entrambi i file system per NFS su alcuni host ed eseguo alcuni lavori. Capisco che non posso scrivere a volumepiù di 5T, perché i restanti 5T sono riservati volume/test.

La mia prima domanda è: come diminuiranno le prestazioni se riempio il mio volumemount point con ~ 5T? Caderà, perché non c'è spazio libero in quel file system per il copy-on-write di ZFS e altre meta-cose? O rimarrà lo stesso, poiché ZFS può utilizzare lo spazio libero all'interno dello spazio riservato volume/test?

Ora la seconda domanda . Fa differenza, se cambio l'installazione come segue? volumeora ha due file system volume/test1e volume/test2. Ad entrambi viene assegnata una prenotazione 3T ciascuno (ma senza quote). Supponiamo ora, scrivo 7T a test1. Le prestazioni per entrambi i file system saranno le stesse o saranno diverse per ogni file system? Cadrà o rimarrà lo stesso?

Grazie!

Sì. Devi mantenere spazio libero nella tua piscina. È principalmente per azioni e istantanee di copia su scrittura. Le prestazioni diminuiscono dell'85% circa. Puoi andare più in alto, ma c'è un impatto definito.

Non scherzare con le prenotazioni. Soprattutto con NFS. Non è necessario. Forse per uno zvol, ma non per NFS.

Non vedo la confusione, però. Se hai 10 T, non usarne più dell'85%. Ridimensiona le tue azioni in modo appropriato, utilizzando le quote per limitare il loro utilizzo. Oppure non utilizzare quote e monitorare l' utilizzo complessivo del pool .

Il deterioramento delle prestazioni si verifica quando zpool è molto pieno o molto frammentato. La ragione di ciò è il meccanismo di rilevamento dei blocchi liberi impiegato con ZFS. A differenza di altri file system come NTFS o ext3, non esiste un bitmap di blocco che mostri quali blocchi sono occupati e quali sono liberi. Invece, ZFS divide il tuo zvol in (di solito 200) aree più grandi chiamate "metaslabs" e memorizza gli alberi AVL ¹ di informazioni di blocco libero (mappa spaziale) in ogni metaslab. L'albero AVL bilanciato consente una ricerca efficiente di un blocco adatto alla dimensione della richiesta.

Sebbene questo meccanismo sia stato scelto per ragioni di scala, sfortunatamente si è rivelato anche un grande dolore quando si verifica un alto livello di frammentazione e / o utilizzo dello spazio. Non appena tutti i metaslabs trasportano una quantità significativa di dati, si ottiene un gran numero di piccole aree di blocchi liberi rispetto a un piccolo numero di grandi aree quando il pool è vuoto. Se ZFS deve quindi allocare 2 MB di spazio, inizia a leggere e valutare le mappe spaziali di tutti i metaslabs per trovare un blocco adatto o un modo per suddividere i 2 MB in blocchi più piccoli. Questo ovviamente richiede del tempo. Quel che è peggio è il fatto che costerà un sacco di operazioni di I / O poiché ZFS legge davvero tutte le mappe spaziali dai dischi fisici . Per qualsiasi tua scrittura.

Il calo delle prestazioni potrebbe essere significativo. Se ti piacciono le belle foto, dai un'occhiata al post del blog su Delphix che ha alcuni numeri tolti da un pool zfs (semplificato ma ancora valido). Sto spudoratamente rubando uno dei grafici: guarda le linee blu, rosse, gialle e verdi in questo grafico che rappresentano (rispettivamente) pool con capacità del 10%, 50%, 75% e 93% tracciate rispetto alla velocità di scrittura in KB / s mentre si frammenta nel tempo:

Una soluzione rapida e sporca a questo è stata tradizionalmente la modalità di debug del metaslab (basta rilasciare echo metaslab_debug/W1 | mdb -kwin fase di esecuzione per modificare immediatamente l'impostazione). In questo caso, tutte le mappe spaziali verrebbero mantenute nella RAM del sistema operativo, eliminando il requisito di I / O eccessivo e costoso su ogni operazione di scrittura. In definitiva, questo significa anche che hai bisogno di più memoria, specialmente per grandi pool, quindi è una specie di RAM per lo scambio di cavalli. Il tuo pool da 10 TB probabilmente ti costerà 2-4 GB di memoria ² , ma sarai in grado di portarlo al 95% di utilizzo senza troppi problemi.

¹ è un po 'più complicato, se sei interessato, guarda il post di Bonwick sulle mappe spaziali per i dettagli

² se hai bisogno di un modo per calcolare un limite superiore per la memoria, usa zdb -mm <pool>per recuperare il numero di segmentsattualmente in uso in ogni metaslab, dividerlo per due per modellare uno scenario peggiore (ogni segmento occupato sarebbe seguito da uno libero ), moltiplicalo per la dimensione del record per un nodo AVL (due puntatori di memoria e un valore, data la natura a 128 bit di zfs e l'indirizzamento a 64 bit sommerebbero fino a 32 byte, sebbene le persone sembrino assumere generalmente 64 byte per alcuni Motivo).

zdb -mm tank | awk '/segments/ {s+=$2}END {s*=32/2; printf("Space map size sum = %d\n",s)}'

Riferimento: lo schema di base è contenuto in questo post di Markus Kovero nella mailing list di zfs-discuss , anche se credo che abbia fatto alcuni errori nel suo calcolo che spero di aver corretto nel mio.