Skip to content

Come posso eseguire il benchmark del mio HDD?

Fai attenzione perché in questo post troverai la sistemazione che stai cercando.

Soluzione:

Di solito uso hdparm per eseguire il benchmark dei miei HDD. È possibile eseguire il benchmark sia delle letture dirette che di quelle in cache. Si consiglia di eseguire i comandi un paio di volte per stabilire un valore medio.

Esempi

Ecco una lettura diretta.

$ sudo hdparm -t /dev/sda2

/dev/sda2:
 Timing buffered disk reads: 302 MB in  3.00 seconds = 100.58 MB/sec

Ed ecco una lettura in cache.

$ sudo hdparm -T /dev/sda2

/dev/sda2:
 Timing cached reads:   4636 MB in  2.00 seconds = 2318.89 MB/sec

Dettagli

-t     Perform  timings  of  device reads for benchmark and comparison 
       purposes.  For meaningful results, this operation should be repeated
       2-3 times on an otherwise inactive system (no other active processes) 
       with at least a couple of megabytes of free memory.  This displays  
       the  speed of reading through the buffer cache to the disk without 
       any prior caching of data.  This measurement is an indication of how 
       fast the drive can sustain sequential data reads under Linux, without 
       any filesystem overhead.  To ensure accurate  measurements, the 
       buffer cache is flushed during the processing of -t using the 
       BLKFLSBUF ioctl.

-T     Perform timings of cache reads for benchmark and comparison purposes.
       For meaningful results, this operation should be repeated 2-3
       times on an otherwise inactive system (no other active processes) 
       with at least a couple of megabytes of free memory.  This displays
       the speed of reading directly from the Linux buffer cache without 
       disk access.  This measurement is essentially an indication of the
       throughput of the processor, cache, and memory of the system under 
       test.

Uso di dd

Anch'io ho usato dd per questo tipo di test. Una modifica che apporterei al comando precedente è quella di aggiungere questo bit alla fine del comando, ; rm ddfile.

$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile

Questo rimuoverà l'opzione ddfile al termine del comando. NOTA:ddfile è un file transitorio che non è necessario conservare. dd sta scrivendo (of=ddfile), quando mette sotto carico l'HDD.

Andando oltre

Se avete bisogno di un test più rigoroso dei vostri HDD, potete usare Bonnie++.

Riferimenti

  • Come usare 'dd' per eseguire il benchmark del disco o della CPU?
  • Benchmark dell'IO del disco con DD e Bonnie++

(Questa è una domanda molto popolare - se ne possono vedere varianti su https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 e https://askubuntu.com/q/87035/740413 )

Esistono metodi migliori [than dd] a [benchmark disks]?

Sì, ma richiedono più tempo per l'esecuzione e la conoscenza di come interpretare i risultati; non esiste un singolo numero che vi dirà tutto in un colpo solo, perché i seguenti fattori influenzano il tipo di test da eseguire:

  • Siete interessati alle prestazioni dell'I/O casuale, sequenziale o di un mix dei due?
  • State leggendo da o scrivendo sul disco (o un misto dei due)?
  • Siete interessati alla latenza, al throughput o a entrambi?
  • Si sta cercando di capire come si comportano le diverse parti dello stesso disco rigido (in genere le velocità sono più vicine al centro dei dischi in rotazione)?
  • Siete interessati a capire come si comporta un determinato filesystem utilizzando il vostro disco o volete risultati più vicini alle prestazioni grezze del disco eseguendo l'I/O direttamente su un dispositivo a blocchi?
  • Siete interessati alle prestazioni di una particolare dimensione di I/O?
  • L'I/O viene inviato in modo sincrono o asincrono?
  • Quanto I/O si sta inviando (se si invia troppo poco nel modo sbagliato, tutto l'I/O potrebbe essere memorizzato nella cache e si finirebbe per testare la velocità della RAM piuttosto che quella del disco)?
  • Quanto è comprimibile il contenuto dei dati che si stanno scrivendo (ad esempio, i dati con solo zero sono altamente comprimibili e alcuni filesystem/dischi hanno persino uno speciale percorso veloce per i dati con solo zero che porta a numeri introvabili con altri contenuti)?

E così via.

Ecco un breve elenco di strumenti, con i più facili da eseguire in cima e i più difficili/più approfonditi/migliori in fondo:

  1. dd (letture o scritture sequenziali, mostra solo il throughput, può essere configurato per usare un filesystem o un dispositivo a blocchi, può essere configurato per bypassare la cache a blocchi/aspettare che l'I/O sia realmente completato)
  2. hdparm (solo letture sequenziali, mostra solo il throughput, non usa mai un filesystem, può essere configurato per bypassare la cache a blocchi, il test della cache rilegge solo i 2 MByte iniziali)
  3. GNOME Disk Utility's benchmark (facile da eseguire, non utilizza mai un filesystem, è grafico ma richiede un'installazione completa di GNOME, fornisce numeri di latenza e throughput per diversi tipi di I/O ma il carico di lavoro in scrittura è in realtà la lettura/scrittura/fsync per dimensione del campione).
  4. fio (può fare quasi tutto e fornisce risultati dettagliati, ma richiede una configurazione e una comprensione di come interpretare tali risultati). Ecco cosa dice Linus al riguardo:

    Greg - prendi il codice FIO di Jens. Fa le cose giuste, compresa la scrittura di contenuti pseudocasuali reali, che mostrano se il disco fa un po' di "de-duplicazione" (alias "ottimizzazione per i benchmark"):

    [ https://github.com/axboe/fio/ ]

    Tutto il resto è sospetto: dimenticatevi di bonnie o di altri strumenti tradizionali.

Fonte: commento lasciato su Google Plus a Greg Kroah-Hartman da Linus Torvalds.

con lo strumento IOPS

Se non si ha il tempo di leggere tutto questo, consiglio semplicemente lo strumento IOPS. Vi dirà la velocità reale in base alla dimensione del blocco.


Per il resto, quando si esegue un benchmark dell'IO, si considerano i seguenti aspetti:

  • blocksize/cache/IOPS/direct vs buffered/async vs sync
  • lettura/scrittura
  • thread
  • latenza
  • Utilizzo della CPU

  • Quale dimensione di blocco utilizzare: Se si vuole leggere/scrivere 1 GB da/su disco, l'operazione di I/O sarà veloce. Ma se l'applicazione ha bisogno di scrivere in pezzi da 512 byte su tutto il disco rigido in modo non sequenziale (chiamato I/O casuale, anche se non è casuale), il risultato sarà diverso. Ora, i database, per loro natura, effettuano I/O casuale per il volume dei dati e I/O sequenziale per il volume dei log. Quindi, per prima cosa è necessario chiarire cosa si vuole misurare. Se si vogliono copiare file video di grandi dimensioni, è diverso dal caso in cui si voglia installare Linux.

    La dimensione del blocco influisce sul numero di operazioni di I/O effettuate. Se ad esempio si eseguono 8 operazioni sequenziali di lettura (o scrittura, ma non miste), lo scheduler I/O del sistema operativo le unirà. Se non lo fa, sarà la cache del controller a unirle. Non c'è praticamente alcuna differenza se si leggono 8 blocchi sequenziali di 512 byte o un blocco di 4096 byte. Un'eccezione è rappresentata dal caso in cui si riesca a eseguire l'IO con sincronizzazione diretta e si attendano i 512 byte prima di richiedere i successivi 512 byte. In questo caso, aumentare la dimensione del blocco è come aggiungere cache.

    Si deve anche sapere che esiste l'IO sync e l'IO async: Con l'IO sincrono non si emette la richiesta di IO successiva prima che quella corrente sia tornata. Con l'IO asincrono si possono richiedere, ad esempio, 10 pezzi di dati e poi aspettare che arrivino. I thread di database distinti utilizzeranno in genere sync IO per il log e async IO per i dati. Lo strumento IOPS se ne occupa misurando tutte le dimensioni dei blocchi a partire da 512 byte.

  • Leggete o scrivete: Di solito la lettura è più veloce della scrittura. Ma si noti che la cache funziona in modo diverso per le letture e le scritture:

    • Per quanto riguarda le scritture, i dati vengono consegnati al controller e, se la cache è presente, viene riconosciuto prima che i dati siano su disco, a meno che la cache non sia piena. Utilizzando lo strumento iozone è possibile disegnare bellissimi grafici dei plateau degli effetti della cache (effetto della cache della CPU ed effetto della cache del buffer). La cache diventa meno efficiente quanto più è stata scritta.

    • Per quanto riguarda la lettura, i dati letti vengono conservati nella cache dopo la prima lettura. Le prime letture richiedono più tempo e la cache diventa sempre più efficace durante il tempo di attività. Le cache più importanti sono la cache della CPU, la cache del file system del sistema operativo, la cache del controller IO e la cache dello storage. Lo strumento IOPS misura solo le letture. Questo permette di "leggere dappertutto" e non si vuole che scriva invece di leggere.

  • Quanti thread utilizzerete: Se si usa un solo thread (usando dd per i benchmark del disco) probabilmente si otterranno prestazioni molto peggiori rispetto a quelle ottenute con più thread. Lo strumento IOPS tiene conto di questo aspetto e legge su più thread.

  • Quanto è importante la latenza per voi: Considerando i database, la latenza dell'IO diventa enormemente importante. Qualsiasi comando SQL di inserimento/aggiornamento/cancellazione viene scritto nel giornale del database ("log" nel gergo dei database) al momento del commit prima che venga riconosciuto. Ciò significa che l'intero database potrebbe essere in attesa del completamento di questa operazione di IO. Qui viene mostrato come misurare il tempo medio di attesa (await) utilizzando il metodo strumento iostat.

  • Quanto è importante per voi l'utilizzo della CPU: La CPU può facilmente diventare il collo di bottiglia delle prestazioni dell'applicazione. In questo caso è necessario sapere quanti cicli della CPU vengono bruciati per ogni byte letto/scritto e ottimizzare in quella direzione. Ciò può significare decidere a favore o contro la memoria flash PCIe in base ai risultati delle misurazioni. Anche in questo caso il valore strumento iostat può fornire una stima approssimativa dell'utilizzo della CPU da parte delle operazioni di IO.

Qui puoi vedere le recensioni e le valutazioni degli utenti

Se ti è piaciuto il nostro lavoro, hai il potere di lasciare un saggio su ciò che ti è piaciuto di questa affermazione.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.