Come influenzano la profondità della coda e la dimensione del blocco la latenza di lettura casuale su un NAS domestico?

La profondità di coda e la dimensione del blocco cambiano la latenza di lettura casuale perché controllano quanto lavoro viene inviato contemporaneamente e quanta dati ogni operazione trasferisce. Un test a bassa profondità di coda e blocco piccolo misura quanto velocemente si completa una richiesta, mentre un test ad alta profondità misura quanto lavoro parallelo il percorso di storage può sostenere.

Lo stesso NAS può quindi mostrare modesti IOPS 4K QD1, IOPS 4K QD32 molto più elevati e un forte throughput con blocchi grandi senza contraddizioni. Ogni risultato descrive un carico di lavoro diverso, e il numero di benchmark più veloce potrebbe essere il meno rappresentativo di un database interattivo, una libreria fotografica o un'app container.

Cosa controllano effettivamente la profondità di coda e la dimensione del blocco?

La profondità di coda è il numero di operazioni I/O in sospeso a un livello misurato. la profondità di coda controlla le richieste I/O in sospeso, mentre la dimensione del blocco definisce il carico trasferito da ogni richiesta.

Un test con QD1 invia un'operazione e attende il completamento prima di emettere la successiva. Un test QD32 consente a molte operazioni di attendere o eseguire in parallelo, offrendo a drive, controller, array e rete maggiori opportunità di sovrapporre il lavoro.

Questi valori esistono a diversi livelli. La coda del thread del benchmark, la coda dei blocchi del sistema operativo, HBA, la coda di sottomissione NVMe, i crediti del protocollo NAS e i singoli dischi possono tutti vedere conteggi di richieste in sospeso differenti.

Perché QD1 espone il tempo di servizio dello storage?

Con una richiesta in sospeso, l'operazione successiva non può nascondersi dietro al lavoro parallelo, quindi QD1 espone il tempo di servizio di una singola richiesta. Il risultato include il tempo di servizio del dispositivo più il protocollo, filesystem, controller, rete e overhead del client.

QD1 è quindi utile per attività rivolte all'utente che emettono una o poche letture dipendenti: apertura dei metadati, caricamento di una pagina di database, lettura di una miniatura o seguire un puntatore alla struttura successiva.

Non si tratta di un test completo della capacità. Un SSD moderno o un array a striping può supportare molto più lavoro parallelo di quanto fornisca QD1, quindi il risultato può sottostimare il massimo IOPS aggregato pur rappresentando accuratamente la reattività di una singola richiesta.

Perché una maggiore profondità di coda può aumentare contemporaneamente IOPS e latenza?

Più lavoro in sospeso può mantenere occupati i canali di storage e aumentare le operazioni completate al secondo, ma una maggiore profondità della coda può aumentare insieme IOPS e latenza. Ogni richiesta può passare più tempo in attesa prima del servizio.

Il benchmark riporta più completamenti totali perché il sistema sovrappone il lavoro, non perché ogni richiesta sia diventata più veloce. Una volta che il dispositivo o l'array raggiunge la sua capacità di servizio, una maggiore profondità della coda allunga principalmente la fila di attesa.

Ecco perché IOPS ad alta profondità di coda e bassa latenza interattiva sono obiettivi separati. Un server di backup o un lavoro di analisi può beneficiare di un parallelismo profondo, mentre una richiesta di app si preoccupa del tempo di completamento di una lettura critica.

Come cambia la dimensione del blocco gli IOPS, il throughput e il tempo di attesa?

Gli IOPS contano le operazioni senza descrivere quanti byte ogni operazione sposta. la dimensione del blocco cambia l'equilibrio tra IOPS e throughput. Mille letture da 4K spostano molti meno dati di mille letture da 128K.

I blocchi piccoli enfatizzano l'overhead per operazione e sono comuni per pagine di database, metadati e stato dell'applicazione. Blocchi più grandi migliorano l'efficienza del trasferimento e la velocità, ma occupano il dispositivo, la rete e il controller per più byte per richiesta.

Un blocco più grande può ridurre il numero di IOPS necessari per una data larghezza di banda aumentando il tempo di servizio di ogni operazione. Le applicazioni miste necessitano di entrambe le dimensioni perché un NAS può servire piccole letture di metadati accanto a grandi trasferimenti di media o backup.

Perché cache e parallelismo fanno sembrare i risultati migliori di come le app si percepiscono?

I risultati del benchmark possono essere dominati dalla RAM, dalla cache del controller, dalla cache del client o dall'accesso ripetuto a un piccolo set di lavoro. cache e concorrenza possono nascondere la latenza della lettura a freddo.

I lavoratori di benchmark paralleli possono anche distribuire le richieste tra dischi, canali NAND, core CPU, canali SMB o code NVMe in modo più efficace rispetto a un singolo thread dell'applicazione. Il test dimostra la scalabilità aggregata, non che una singola lettura a freddo dell'app riceva lo stesso beneficio.

Usare un set di dati più grande delle cache rilevanti quando si testa il supporto di archiviazione, ed eseguire test separati con cache calda quando la memorizzazione nella cache dell'applicazione fa parte del design reale. Mescolare i due produce un numero il cui collo di bottiglia non è chiaro.

Come dovrebbe un test di lettura casuale di un NAS domestico corrispondere ai carichi di lavoro reali?

Un benchmark utile varia le dimensioni che le applicazioni reali variano. i test realistici devono corrispondere alla profondità di coda del carico di lavoro invece di riportare un unico valore massimo di IOPS.

Testare QD1 e alcune profondità moderate, includere letture piccole da 4K o 8K e i blocchi più grandi usati da strumenti multimediali o di backup, e registrare la latenza media più p95, p99 e massima. Mantenere costanti client, protocollo, crittografia e set di dati quando si confrontano cambiamenti di archiviazione.

Eseguire il test di lettura casuale sia da solo che accanto ai carichi di lavoro in background che effettivamente condividono il NAS. Un benchmark isolato può misurare il percorso di archiviazione in modo pulito, ma non può rivelare la latenza che gli utenti sperimentano durante app, backup, indicizzazione o contesa di parità.

FAQ

Una profondità di coda più alta è sempre meglio?

No. Può migliorare la velocità aggregata fino a saturare il percorso di archiviazione, ma le richieste possono attendere più a lungo e la latenza interattiva può peggiorare.

Perché i numeri di lettura casuale a 4K sono comunemente riportati?

I blocchi piccoli assomigliano a pagine di database, metadati e stato dell'applicazione, e mettono in evidenza l'overhead per operazione che i trasferimenti sequenziali grandi nascondono.

Un benchmark NAS dovrebbe usare QD32?

Solo quando il carico di lavoro previsto può generare tanto I/O parallelo. Includere QD1 e profondità moderate per applicazioni server domestiche interattive.

La latenza di rete può dominare un test di lettura casuale?

Sì. I viaggi di andata e ritorno SMB o NFS, l'elaborazione client, la crittografia e le code degli switch possono superare il tempo di servizio del dispositivo, specialmente a bassa profondità di coda.

Conclusione finale

La profondità della coda determina quante operazioni di I/O possono attendere o essere eseguite in parallelo, mentre la dimensione del blocco determina quanta dati ogni operazione sposta. Una profondità di coda maggiore può aumentare il totale degli IOPS aumentando però la latenza per richiesta, e blocchi più grandi possono migliorare la velocità di trasferimento riducendo il numero di operazioni. Un benchmark utile per un NAS domestico corrisponde alla reale concorrenza, dimensioni dei dati, stato della cache e requisiti di latenza di coda, invece di selezionare il numero massimo in evidenza.