Risultati benchmark
A questo punto verranno esaminati i risultati del benchmark per verificare i suggerimenti sulle prestazioni illustrati nell'unità precedente. In particolare, ci si concentrerà sull'uso della suite di benchmark SPEC SFS per generare più thread che simulano carichi di lavoro di tipo produzione EDA. Verranno anche mostrati i risultati FIO per esaminare alcune procedure relative alle prestazioni.
Panoramica dei due strumenti di benchmark
La suite SPEC SFS è un benchmark di settore standard per EDA. Il carico di lavoro EDA tipico è costituito da fasi funzionali e fisiche. La fase funzionale determina principalmente operazioni sui metadati del file system e operazioni di I/O casuali. La fase fisica determina operazioni di lettura e scrittura sequenziali a blocchi di grandi dimensioni.
FIO è uno strumento di I/O in grado di generare carichi di lettura/scrittura casuali o sequenziali coerenti per eseguire il benchmark delle operazioni di I/O al secondo e della velocità effettiva della destinazione di archiviazione.
Tipi di volume in Azure NetApp Files
Azure NetApp Files offre due tipi di volumi di cui è possibile eseguire il provisioning per l'archiviazione dei dati cloud: volumi regolari e volumi di grandi dimensioni. La tabella seguente evidenzia alcune delle differenze principali tra i due tipi di volume. Usare questa tabella come indicazioni quando si sceglie il tipo di volume appropriato per il carico di lavoro.
| Limite | Volume regolare | Volume di grandi dimensioni |
|---|---|---|
| Capacità minima | 100 GiB | 50 TiB |
| Capacità massima | 100 TiB | 500 TiB |
| Livello di servizio minimo supportato | Standard | Standard |
| Velocità effettiva massima osservata | 4.500 MiB/s | 10.240 MiB/s |
| Numero massimo di operazioni di I/O al secondo di lettura osservate | ~200.000 | ~700.000 |
| Numero massimo di operazioni di I/O al secondo di scrittura osservate | ~135.000 | ~474.000 |
Risultati del benchmark dello strumento SPEC EDA per volumi regolari
I grafici di questa sezione illustrano le curve di I/O e latenza, esaminando alcune combinazioni delle procedure di prestazioni seguenti:
nocto,actimeo=600sysctl tunednconnect=16
Quando vengono applicate tutte e tre le procedure precedenti, le operazioni di I/O al secondo aumentano e mantengono una bassa latenza (inferiore a 1 millisecondo).
Il grafico seguente dimostra che NFSv3 offre prestazioni migliori rispetto a NFSv4.1 per questo tipo di carico di lavoro.
Il grafico seguente dimostra che rsize=wsize=262144(256 K) offre prestazioni migliori rispetto ad altre impostazioni.
Risultati del benchmark dello strumento SPEC EDA per volumi di grandi dimensioni
I test delle soglie di prestazioni sono stati eseguiti su un singolo volume di grandi dimensioni usando il benchmark SPEC SFS con la configurazione seguente:
| Tipo configurazione | Impostazione |
|---|---|
| Sistema operativo | RHEL 9.3 / RHEL 8.7 |
| Tipo di istanza | D16s_v5 |
| Numero di istanze | 10 |
| Opzioni di montaggio | nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8 |
I test hanno confrontato le funzionalità di prestazioni di un volume di grandi dimensioni usando il benchmark SPEC SFS rispetto a un volume normale in Azure NetApp Files.
| Scenario | Velocità di I/O a 2 ms | MiB/s a 2 ms |
|---|---|---|
| Un volume regolare | 39.601 | 692 |
| Un volume di grandi dimensioni | 652.260 | 10.030 |
Risultati del benchmark dello strumento FIO per volumi regolari
Sono riportati di seguito i comandi FIO per il benchmark delle operazioni di I/O al secondo e della velocità effettiva, rispettivamente.
// FIO commands to benchmark IOPS:
// 8K Random Reads
fio --name=8krandomreads --rw=randread --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 8K Random Writes
fio --name=8krandomwrites --rw=randwrite --direct=1 --ioengine=libaio --bs=8k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// FIO commands to benchmark throughput:
// 64K Sequential Reads
fio --name=64kseqreads --rw=read --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
// 64K Sequential Writes
fio --name=64kseqwrites --rw=write --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --iodepth=128 --size=4G --runtime=600 --group_reporting
I due grafici seguenti dimostrano che quando nocto,actimeo=600, nconnect=16 e sysctl sono ottimizzati, Azure NetApp Files è in grado di ottenere un numero maggiore di operazioni di I/O al secondo e una velocità effettiva più elevata.
Risultati del benchmark dello strumento FIO per volumi di grandi dimensioni
Questa sezione descrive le soglie delle prestazioni di un singolo volume di grandi dimensioni usando il benchmark FIO. I test sono stati eseguiti con la configurazione seguente:
| Componente | Impostazione |
|---|---|
| Dimensioni della macchina virtuale Azure | E32s_v5 |
| Limite di larghezza di banda in uscita della macchina virtuale di Azure | 2000 MiB/s (2 GiB/s) |
| Sistema operativo | RHEL 8.4 |
| Volume di grandi dimensioni | 101 TiB Ultra (velocità effettiva 10.240 MiB/s) |
| Opzioni di montaggio | hard,rsize=65536,wsize=65536,vers=3 NOTA: L'uso di 262144 e 65536 ha avuto risultati di prestazioni simili. |
Carichi di lavoro sequenziali da 256 KiB (MiB/s)
Il grafico rappresenta un carico di lavoro sequenziale di 256 KiB e un working set di 1 TiB. Mostra che un singolo volume di Azure NetApp Files può gestire tra circa 8.518 MiB/s scritture sequenziali pure e 9.970MiB/s letture sequenziali pure.
Carico di lavoro casuale a 8 KiB (operazioni di I/O al secondo)
Il grafico rappresenta un carico di lavoro casuale da 8 KiB e un working set di 1 TiB. Il grafico mostra che un volume di grandi dimensioni di Azure NetApp Files può gestire tra circa 474.000 scritture casuali pure e circa 709.000 letture casuali pure.
