Domanda Come controllare le prestazioni del disco rigido


Come verificare le prestazioni di un disco rigido (tramite terminale o interfaccia grafica). La velocità di scrittura. La velocità di lettura Dimensione e velocità della cache. Velocità casuale


260
2017-12-12 00:22


origine


Una domanda simile è stata chiesta oltre unix.stackexchange.com/questions/108838/... , stackoverflow.com/questions/1198691/... e serverfault.com/questions/219739/... . - Anon


risposte:


Metodo terminale

hdparm è un buon punto di partenza.

sudo hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads:   12540 MB in  2.00 seconds = 6277.67 MB/sec
Timing buffered disk reads: 234 MB in  3.00 seconds =  77.98 MB/sec

sudo hdparm -v /dev/sda darà anche informazioni.

dd ti darà informazioni sulla velocità di scrittura.

Se l'unità non ha un file system (e solo allora), uso of=/dev/sda.

Altrimenti, montarlo su / tmp e scrivere, quindi eliminare il file di output di test.

dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output

10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s

Metodo grafico

  1. Vai a Sistema -> Amministrazione -> Utility Disco.
    • In alternativa, avviare l'utilità del disco Gnome dalla riga di comando eseguendo gnome-disks
  2. Seleziona il tuo hard disk nel riquadro sinistro.
  3. Ora fai clic sul pulsante "Benchmark - Misura prestazioni unità" nel riquadro di destra.
  4. Si aprirà una nuova finestra con i grafici. Troverete e due pulsanti. Uno è per "Inizia solo il benchmark di lettura" e un altro è "Inizia lettura / Scrivi benchmark". Quando fai clic sul pulsante di qualcuno, inizia il benchmarking del disco rigido.

test

Come confrontare l'I / O del disco

Articolo

C'è qualcosa che vuoi di più?


342
2017-12-12 00:34



Consiglierei il test /dev/urandom così come /dev/zero come input per dd quando si verifica un SSD, la compressibilità dei dati può avere un enorme effetto sulla velocità di scrittura. - Ian Mackinnon
Non esiste un tale "Sistema ->" sulla mia Ubuntu 12.04 Unity. O almeno non l'ho trovato. E non vedo lo strumento disco nemmeno all'interno delle Impostazioni di sistema ... O_o Ma sono riuscito a farlo funzionare: / usr / bin / palimpsest - Fran Marzoa
Si noti che dal 12.10 è semplicemente chiamato Disks e può essere trovato attraverso Unity. - Paul Lammertsma
Su Gnome questo è stato spostato in Applicazioni -> Strumenti di sistema -> Preferenze -> Utility Disco. Per quelli di uso che odiano l'unità. - Ken Sharp
Il /tmp il filesystem usa spesso un ramdisk in questi giorni. Quindi scrivendo a /tmp sembrerebbe testare la tua memoria, non il tuo sottosistema di dischi. - Zoredache


Suominen ha ragione, dovremmo usare una specie di sincronizzazione; ma c'è un metodo più semplice, conv = fdatasync farà il lavoro:

dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
1024+0records in
1024+0 records out
402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/s

73
2017-08-18 18:31



È una risposta che usa un comando / opzione diversa dagli altri. Vedo che è una risposta degna di un post. - Alaa Ali
Perché hai usato 384k come dimensione del blocco? - Diego F. Durán
@Diego Non c'è motivo. Era solo un esempio. Puoi usare qualsiasi altra cosa. (tra circa 4k ... 1M) Naturalmente blocchi più grandi daranno prestazioni migliori. E naturalmente diminuisci il numero di conteggi quando usi big bs, o ci vorrà un anno per finire. - Tele
non è affidabile con strumenti benchmark come iozone e i numeri sysbench sono molto più bassi - MSS


Non raccomanderei l'uso /dev/urandom perché è basato su software e lento come maiale. Meglio prendere un po 'di dati casuali su ramdisk. Sul test del disco rigido casuale non importa, perché ogni byte è scritto come è (anche su ssd con dd). Ma se testiamo il pool zfs deduplicato con zero puro o dati casuali, c'è un'enorme differenza di prestazioni.

Un altro punto di vista deve essere l'inclusione del tempo di sincronizzazione; tutti i moderni filesystem utilizzano la memorizzazione nella cache delle operazioni sui file.

Per misurare realmente la velocità del disco e non la memoria, dobbiamo sincronizzare il filesystem per eliminare l'effetto di memorizzazione nella cache. Questo può essere fatto facilmente da:

time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"

con quel metodo ottieni l'output:

sync ; time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k  && sync" ; rm testfile 
1024+0 records in
1024+0 records out
104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/s

real    0m0.441s
user    0m0.004s
sys 0m0.124s

quindi il disco datarate è solo 104857600 / 0,441 = 237772335 B / s -> 237 MB / s

Questo è più di 100 MB / s in meno rispetto al caching.

Buon benchmarking,


42
2017-12-06 23:18





Se si desidera monitorare la velocità di lettura e scrittura del disco in tempo reale, è possibile utilizzare iotop strumento.

Questo è utile per ottenere informazioni esatte su come si comporta un disco per una particolare applicazione o attività. L'output mostrerà la velocità di lettura / scrittura per processo e la velocità di lettura / scrittura totale per il server, molto simile a top.

Per installare iotop:

sudo apt-get install iotop  

Per eseguirlo:

sudo iotop

30
2017-09-17 14:24





bonnie ++ è l'ultima utility di benchmark che conosco per Linux.

(Attualmente sto preparando un linux livecd al lavoro con bonnie ++ su di esso per testare la nostra macchina basata su Windows!)

Si occupa della cache, sincronizzazione, dati casuali, posizione casuale su disco, aggiornamenti di piccole dimensioni, aggiornamenti di grandi dimensioni, letture, scritture, ecc. Confronto tra un tasto usb, un disco rigido (rotativo), un'unità a stato solido e un ram il filesystem può essere molto informativo per il principiante.

Non ho idea se sia incluso in Ubuntu, ma puoi facilmente compilarlo dalla fonte.

http://www.coker.com.au/bonnie++/


23
2018-02-03 16:13





Velocità di scrittura

$ dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/s

La dimensione del blocco è in realtà piuttosto grande. Puoi provare con dimensioni più piccole come 64k o anche 4k.


Leggi la velocità

Eseguire il seguente comando per cancellare la memoria cache

$ sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"

Ora leggi il file che è stato creato nel test di scrittura:

$ dd if=./largefile of=/dev/null bs=4k
165118+0 records in
165118+0 records out
676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/s

17
2018-05-05 22:12





alcuni suggerimenti su come usare bonnie ++

bonnie++ -d [TEST_LOCATION] -s [TEST_SIZE] -n 0 -m [TEST_NAME] -f -b -u [TEST_USER] 
bonnie++ -d /tmp -s 4G -n 0 -m TEST -f -b -u james

Un po 'di più a: SEMPLICE BONNIE ++ ESEMPIO.


12
2017-09-28 19:02





Se vuoi la precisione, dovresti usare fio. Richiede la lettura del manuale (man fio) ma ti darà risultati accurati. Si noti che per qualsiasi precisione, è necessario specificare esattamente ciò che si desidera misurare. Qualche esempio:

Velocità di lettura sequenziale con blocchi grandi (questo dovrebbe essere vicino al numero che vedi nelle specifiche per la tua unità):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Velocità SCRITTURA sequenziale con blocchi grandi (questo dovrebbe essere vicino al numero che vedi nelle specifiche per la tua unità):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Random 4K ha letto QD1 (questo è il numero che conta davvero per le prestazioni del mondo reale a meno che tu non lo sappia di sicuro):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Mixed random 4K lettura e scrittura QD1 con sincronizzazione (questo è il numero peggiore che ti aspetti dal tuo disco, solitamente dall'1 al 10% del numero indicato nella scheda tecnica):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Aumentare il --size argomento per aumentare la dimensione del file. L'uso di file più grandi può ridurre i numeri che si ottengono in base alla tecnologia e al firmware dell'unità. I file di piccole dimensioni danno risultati "troppo buoni" per i supporti di rotazione perché la testina di lettura non deve spostarsi più di tanto. Se il tuo dispositivo è quasi vuoto, l'utilizzo di un file abbastanza grande da riempire quasi l'unità ti darà il comportamento peggiore per ogni test. In caso di SSD, le dimensioni del file non contano molto.

Nota che fio creerà il file temporaneo richiesto alla prima esecuzione. Sarà riempito con dati casuali per evitare di ottenere numeri troppo buoni da dispositivi che imbrogliano comprimendo i dati prima di scriverli in una memoria permanente. Il file temporaneo verrà chiamato fio-tempfile.dat negli esempi precedenti e memorizzati nella directory di lavoro corrente. Quindi dovresti prima passare alla directory che è montata sul dispositivo che vuoi testare.


9
2018-01-01 18:14



Alcune delle impostazioni di fio sono un po 'strane e potrebbero non essere ottimali. Ad esempio, avere una dimensione di blocco così grande (2Mbytes) quando si sta eseguendo l'I / O diretto con un motore I / O asincrono rischia di portare a molte scissioni nel kernel, creando così un sovraccarico. Invio periodico fsyncs quando stai facendo solo le letture ha anche un aspetto insolito. Sono d'accordo che fio è utile, ma consiglierei ai lettori di esaminare attentamente i parametri che desiderano utilizzare piuttosto che copiarli alla lettera della versione 20180102 della precedente ... - Anon
@ Non: hai ragione, l'ideale per la lettura sequenziale sarebbe quello di corrispondere /sys/block/sd?/queue/max_sectors_kb perché potrebbe essere inferiore al limite hardware effettivo che è in genere molto più di 2 MB nell'esempio sopra. Tuttavia, suppongo che il sovraccarico minore causato dalla CPU non sia importante rispetto alla velocità del dispositivo I / O reale. Il fsync è una non operazione per le letture, quindi non influenzerà i risultati - l'ho tenuto in modo che sia più facile capire le differenze tra le diverse linee di comando. Hai problemi a ottenere risultati che corrispondano alle specifiche del produttore? - Mikko Rantalainen
Non esattamente, ho solo (qualche) esperienza di lavoro con fio e Linux. In realtà se stai indovinando la dimensione del blocco migliore sarebbe saggio iniziare con optimum_io_size se è disponibile (ma puoi assumere 64 KB se è 0 - questo è ciò che fa il kernel). Non esattamente, ho solo (qualche) esperienza di lavoro con fio e Linux. In realtà, se stai indovinando la dimensione del blocco migliore, sarebbe opportuno iniziare con optimum_io_size se è disponibile (ma puoi assumere 64 KB se è 0 - questo è ciò che fa il kernel). - Anon
Ho appena provato nuovamente alcuni dispositivi. Usando il test di lettura sequenziale sopra (dimensione del blocco di 2 MB) ho ottenuto 280 MB / s da Samsung SSD 850 EVO e 1070 MB / s da Intel 910 SSD. Con una dimensione del blocco di 64k e una riga di comando identica, ho ottenuto 268 MB / s da 850 EVO e 1055 MB / s da 910 SSD. Almeno per questo tipo di dispositivi, l'utilizzo di blocchi da 2 MB sembra migliorare i risultati intorno all'1-5%, anche se ciò fa sì che il kernel divida le richieste all'hardware. Suppongo che anche con le ottimizzazioni del kernel il sovraccarico di invio di più syscalls sia peggio che la suddivisione all'interno del kernel. - Mikko Rantalainen
Dopo ulteriori test, sembra che ottenga il più alto throughput sequenziale utilizzando la potenza di 2 valore inferiore a max_sectors_kb. Ho modificato i comandi di esempio sopra per utilizzare la dimensione del blocco di 1 MB perché sembra funzionare con l'hardware del mondo reale. E l'ho anche provato fsync non importa per la lettura. - Mikko Rantalainen