Pronti a tutto
Finora, non abbiamo usato il disk caching di Linux per aumentare i numeri dei benchmark. A differenza della maggior parte delle schede RAID hardware mainstream e di fascia più alta, non abbiamo necessariamente un equivalente diretto mentre usiamo mdadm e Linux. Almeno, non in RAID 0.
Allochiamo un determinato numero di pagine di memoria per drive in RAID 5/6, e questo si traduce in qualcosa di simile alla cache DRAM ad alta velocità presente sulle schede come le 9266-8i di LSI.
Linux è furbo, però. Qualsiasi memoria non esplicitamente allocata viene usata per il caching, e se la memoria è necessaria per altre operazioni, viene liberata. Nel nostro caso, i 64 GB di memoria DDR3-1333 di Kingston sono perlopiù liberi per il caching o il filesystem, dal momento che il nostro server non usa tanta RAM con CentOS 6.
Quando si tratta di testare gruppi di drive, è preferibile disabilitare il caching per sapere cosa possono fare gli SSD. Ora che già sappiamo le prestazioni, vediamo che cosa succede quando mixiamo due controller di memoria quad-channel e otto moduli 1333 MT/s.
Test sequenziale 4 KB, I/O in cache
Quando lasciamo la cache dell'OS composta di trasferimenti casuali 4 KB, vediamo differenti prestazioni rispetto a quelle già riportate. C'è del potenziale per numeri migliori, ma solo se il sistema richiede i dati all'interno della memoria. Il software sa solo come mettere in cache gli LBA all'interno della DRAM se sono già stati "visitati" durante una sessione.
Le letture casuali 4 KB sono state testate con queue depth da uno a 32, usando da uno a 32 thread. La classifica qui sotto riflette i risultati di 36 di queste sessioni per creare una matrice di test da 20 secondi.
In questa quantità di tempo ridotta, il sistema non ha davvero la possibilità di accedere a molti LBA più di una volta. Con il nostro generatore di carico casuale che decide quale LBA del range di test scegliere, alcuni indirizzi potrebbero essere visitati diverse volte, mentre altri solo una volta o del tutto ignorati.
Testare con il caching permette di avere un quadro chiaro delle prestazioni. Se permettiamo alla configurazione a 24 drive di mettere dati in cache, osserviamo qualcosa di leggermente diverso.
La prima e la seconda classifica sono fondamentalmente lo stesso test. Il primo non beneficia del caching, mentre l'altro sì. Le prestazioni con queue depth e numero di thread più bassi sono decisamente migliori, anche se meno costanti. Non appena incontriamo carichi più pesanti, l'array non può raggiungere lo stesso numero di transazioni al secondo viste nel test senza caching. In questo scenario, la prestazione massima è più bassa, ma la prestazione minima è migliore.
Quella dinamica viene sovvertita quando passiamo ai trasferimenti sequenziali.
Test sequenziale 128 KB, I/O in cache
Restringendo il range di LBA testato a soli 32 GB, possiamo effettivamente mettere in cache l'intera area di test all'interno della DRAM. Non richiede troppo, specialmente quando leggiamo e scriviamo migliaia di megabyte al secondo. Abbiamo fatto girare il test per 10 minuti, e poi rilevato il bandwidth medio in MB/s.
Non conta quanti drive ci sono nell'array. L'intero spazio LBA da 32 GB è messo in cache all'interno di secondi, dopodiché abbiamo fino a 23.000 MB/s di bandwidth in lettura dopo una sessione di 10 minuti di test. Anche con le scritture abbiamo generato un sacco di throughput, ovvero 14 GB/s.
È un po' come barare, ma è così? Non necessariamente. Stiamo semplicemente osservando ciò che accade quando lasciamo fare al sistema operativo quello che vuole.
Max IOPS
Abbiamo visto cosa può fare il caching per i trasferimenti sequenziali, e come influenza le prestazioni casuali all'interno di uno scenario di test definito. Se vogliamo ricercare il massimo dell'I/O, dobbiamo mescolare le due metodologie insieme.
Anzitutto, creiamo un carico di lavoro in lettura casuale 4 KB, distribuito su uno spazio LBA da 32 GB, e poi l'abbiamo fatto girare per alcuni minuti. Dopo un po', il sistema mette in cache l'intera area LBA da 32 GB e sentiamo l'intero effetto di servire richieste direttamente dalla RAM. Fino a dove ci possiamo spingere?
La risposta? Fino a 3.136.000 IOPS, oppure oltre 12.000 MB/s. A questo punto, stiamo usando tutta la potenza di calcolo del nostro server dual-Xeon. Generare il carico per spingere così tante I/O è un duro lavoro, che si somma alle funzioni supplementari di gestione dei calcoli RAID che si fanno più intense. Dopo diverse prove ed errori, 3.136M IOPS è il meglio che possiamo fare.