Procedure consigliate per l'I/O diretto di Linux per Azure NetApp Files

  • Articolo

Questo articolo illustra le procedure consigliate di I/O dirette per Azure NetApp Files.

I/O diretto

Il parametro più comune usato nel benchmarking delle prestazioni di archiviazione è L'I/O diretto. È supportato da FIO e Vdbench. DISKSPD offre supporto per il costrutto simile di I/O mappato alla memoria. Con l'I/O diretto, la cache del file system viene ignorata, le operazioni per la copia diretta dell'accesso alla memoria vengono evitate e i test di archiviazione vengono resi rapidi e semplici.

L'uso del parametro I/O diretto semplifica i test di archiviazione. Nessun dato viene letto dalla cache del file system nel client. Di conseguenza, il test sta veramente stressando il protocollo di archiviazione e il servizio stesso, anziché velocità di accesso alla memoria. Senza le copie di memoria DMA, le operazioni di lettura e scrittura sono efficienti dal punto di vista dell'elaborazione.

Eseguire il comando Linux dd come carico di lavoro di esempio. Senza il flag facoltativo odirect , tutte le operazioni di I/O generate da dd vengono gestite dalla cache del buffer Linux. Le letture con i blocchi già in memoria non vengono recuperate dall'archiviazione. Le letture che causano un mancato riscontro nella cache del buffer finiscono per essere lette dall'archiviazione usando NFS read-ahead con risultati variabili, a seconda dei fattori come il montaggio rsize e i ottimizzabili read-ahead del client. Quando le scritture vengono inviate tramite la cache del buffer, usano un meccanismo write-behind, che non è ottimizzato e usa una notevole quantità di parallelismo per inviare i dati al dispositivo di archiviazione. È possibile tentare di eseguire due flussi indipendenti di I/O, uno dd per le letture e uno dd per le scritture. Ma in realtà, il sistema operativo, non ottimizzato, favorisce le scritture sulle letture e usa un maggiore parallelismo di esso.

Oltre al database, poche applicazioni usano operazioni di I/O dirette. Sfruttano invece i vantaggi di una cache di memoria di grandi dimensioni per letture ripetute e una scrittura dietro la cache per le scritture asincrone. In breve, l'uso diretto dell'I/O trasforma il test in un micro benchmark se l'applicazione sintetizzata usa la cache del file system.

Di seguito sono riportati alcuni database che supportano l'I/O diretto:

  • Oracle
  • SAP HANA
  • MySQL (motore di archiviazione InnoDB)
  • RocksDB
  • PostgreSQL
  • Teradata

Procedure consigliate

Il test con directio è un ottimo modo per comprendere i limiti del servizio di archiviazione e del client. Per comprendere meglio il comportamento dell'applicazione (se l'applicazione non usa directio), è anche necessario eseguire test tramite la cache del file system.

Passaggi successivi