Come posso confrontare il mio HDD?

Di solito uso hdparm per confrontare i miei HDD. Puoi eseguire il benchmark sia delle letture dirette che delle letture memorizzate nella cache. Ti consigliamo 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 memorizzata nella 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.

Usando dd

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

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

Questo rimuoverà il ddfile dopo che il comando è stato completato. NOTA: ddfile è un file transitorio che non è necessario conservare, è il file che dd sta scrivendo a (of=ddfile ), quando sta caricando l'HDD.

Andare oltre

Se hai bisogno di test più rigorosi dei tuoi HDD, puoi usare Bonnie++.

Riferimenti

• Come utilizzare 'dd' per eseguire il benchmark del disco o della CPU?
• Esegui benchmark IO su disco con DD e Bonnie++

(Questa è una domanda molto popolare:puoi vederne le variazioni su https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 e https://askubuntu.com/q /87035/740413 )

Esistono metodi migliori [rispetto a dd] per [dischi benchmark]?

Sì, ma richiederanno più tempo per essere eseguiti e richiederanno la conoscenza di come interpretare i risultati:non esiste un singolo numero che ti dirà tutto in una volta perché quanto segue influenza il tipo di test che dovresti eseguire:

• Sei interessato alle prestazioni di I/O che sono casuali, sequenziali o una combinazione dei due?
• Stai leggendo o scrivendo sul disco (o una combinazione dei due)?
• Sei preoccupato per la latenza, il throughput o entrambi?
• Stai cercando di capire come si comportano diverse parti dello stesso disco rigido (generalmente velocità più elevate vicino al centro dei dischi rotanti)?
• Sei interessato a come funzionerà un dato filesystem quando usi il tuo disco o vuoi risultati più vicini alle prestazioni grezze del disco eseguendo l'I/O direttamente su un dispositivo a blocchi?
• Sei interessato a come si comporta una particolare dimensione di I/O?
• Stai inviando l'I/O in modo sincrono o asincrono?
• Quanto I/O stai inviando (invia troppo poco nel modo sbagliato e tutto l'I/O potrebbe essere memorizzato nella cache, quindi finisci per testare la velocità della tua RAM piuttosto che la velocità del disco)?
• Quanto è comprimibile il contenuto dei dati che stai scrivendo (ad es. i dati solo zero sono altamente comprimibili e alcuni filesystem/dischi hanno persino uno speciale percorso rapido per i dati solo zero che portano a numeri che non sono ottenibili con altri contenuti)?

E così via.

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

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

   Greg, prendi il codice FIO di Jens. Fa le cose per bene, inclusa la scrittura di contenuti pseudo-casuali effettivi, che mostrano se il disco esegue una "deduplicazione" (ovvero "ottimizzazione per i benchmark):

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

   Qualsiasi altra cosa è sospetta:dimentica Bonnie o altri strumenti tradizionali.

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

con lo strumento IOPS

Se non puoi essere disturbato a leggere tutto questo, ti consiglio semplicemente lo strumento IOPS. Ti dirà la velocità del mondo reale a seconda della dimensione del blocco.

Altrimenti, quando eseguo un benchmark IO guarderei le seguenti cose:

• blocksize/cache/IOPS/direct vs buffered/async vs sync
• leggere/scrivere
• thread
• latenza

• Utilizzo della CPU

• Quale blocksize utilizzerai :Se si desidera leggere/scrivere 1 GB da/su disco, questo sarà rapido se si esegue un'operazione di I/O. Ma se la tua applicazione ha bisogno di scrivere in blocchi di 512 byte in tutto il disco rigido in pezzi non sequenziali (chiamati I/O casuali sebbene non sia casuale) questo avrà un aspetto diverso. Ora, i database eseguiranno I/O casuali per il volume di dati e I/O sequenziali per il volume di registro a causa della loro natura. Quindi, prima devi chiarire cosa vuoi misurare. Se vuoi copiare file video di grandi dimensioni è diverso da se vuoi installare Linux.

  Questa dimensione del blocco sta influenzando il conteggio delle operazioni di I/O che fai. Se lo fai ad es. 8 operazioni sequenziali di lettura (o scrittura, ma non miste) lo scheduler I/O del sistema operativo le unirà. In caso contrario, la cache del controller eseguirà l'unione. Non c'è praticamente alcuna differenza se leggi 8 blocchi sequenziali di 512 byte o un blocco di 4096 byte. Un'eccezione:se riesci a eseguire l'IO di sincronizzazione diretta e attendi i 512 byte prima di richiedere i successivi 512 byte. In questo caso, aumentare la dimensione del blocco è come aggiungere cache.

  Inoltre, dovresti essere consapevole che esiste IO sincronizzato e asincrono:con IO sincronizzato non emetterai la successiva richiesta IO prima che ritorni quella corrente. Con async IO puoi richiedere ad es. 10 pezzi di dati e poi aspetta che arrivino. I thread di database distinti useranno in genere l'IO di sincronizzazione per il log e l'IO asincrono per i dati. Lo strumento IOPS se ne occupa misurando tutte le dimensioni dei blocchi rilevanti a partire da 512 byte.

• Leggerai o scriverai :Solitamente la lettura è più veloce della scrittura. Ma nota che la memorizzazione nella cache funziona in un modo abbastanza diverso per le letture e le scritture:

  • Per le scritture, i dati verranno trasferiti al controller e, se li memorizza nella cache, riconoscerà prima che i dati siano su disco, a meno che la cache non sia piena. Usando lo strumento iozone puoi disegnare bellissimi grafici degli altipiani degli effetti cache (effetto cache CPU ed effetto cache buffer). Le cache diventano meno efficienti quanto più è stato scritto.

  • Per le letture, i dati letti vengono conservati nella cache dopo la prima lettura. Le prime letture richiedono più tempo e la memorizzazione nella cache diventa sempre più efficace durante il tempo di attività. Le cache notevoli 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 solo misure leggere. Questo gli permette di "leggere ovunque" e tu non vuoi che scriva invece di leggere.

• Quanti thread utilizzerai :Se usi un thread (usando dd per i benchmark del disco) probabilmente otterrai prestazioni molto peggiori rispetto a più thread. Lo strumento IOPS ne tiene conto e legge su diversi thread.

• Quanto è importante per te la latenza :Guardando i database, la latenza IO diventa enormemente importante. Qualsiasi comando SQL di inserimento/aggiornamento/cancellazione verrà scritto nel journal del database ("log" nel gergo del database) al momento del commit prima che venga riconosciuto. Ciò significa che il database completo potrebbe essere in attesa del completamento di questa operazione di I/O. Mostro qui come misurare il tempo medio di attesa (wait) usando lo strumento iostat .

• Quanto è importante per te l'utilizzo della CPU :La tua CPU potrebbe facilmente diventare il collo di bottiglia per le prestazioni della tua applicazione. In questo caso devi sapere quanti cicli della CPU vengono bruciati per byte letto/scritto e ottimizzare in quella direzione. Questo può significare decidere a favore/contro la memoria flash PCIe a seconda dei risultati della misurazione. Di nuovo lo strumento iostat può darti una stima approssimativa dell'utilizzo della CPU da parte delle tue operazioni di IO.