Risposte:
Di solito lo uso hdparmper confrontare i miei HDD. È possibile eseguire il benchmark sia delle letture dirette sia delle letture memorizzate nella cache. Ti consigliamo di eseguire i comandi un paio di volte per stabilire un valore medio.
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 cache.
$ sudo hdparm -T /dev/sda2
/dev/sda2:
Timing cached reads: 4636 MB in 2.00 seconds = 2318.89 MB/sec
-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.
Anch'io ho usato ddper questo tipo di test. Una modifica che vorrei fare al comando precedente è quello di aggiungere questo bit alla fine del vostro comando, ; rm ddfile.
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
Ciò rimuoverà ddfiledopo il completamento del comando. NOTA: ddfile è un file temporaneo che non è necessario conservare, è il file che ddsta scrivendo su ( of=ddfile), quando sta caricando il disco fisso.
Se hai bisogno di test più rigorosi dei tuoi HDD puoi usare Bonnie ++ .
hdparmanche, per benchmark rapidi. L'unico aspetto negativo è che solo i benchmark leggono la larghezza di banda e le prestazioni di molti tipi di dispositivi a blocchi (ad esempio RAID, iSCSI) possono essere molto asimmetriche. Per confrontare le prestazioni 'prima' e 'dopo' sulla stessa scatola, ddfunziona anche bene.
hdparm+ ddo solo bonnie++o tutti 3.
(Questa è una domanda molto popolare: puoi vederne le varianti su https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 e https://askubuntu.com/q / 87035/740413 )
Esistono metodi migliori [di dd] per [dischi di riferimento]?
Sì, ma richiederanno più tempo per essere eseguiti e richiedono la conoscenza di come interpretare i risultati: non esiste un unico numero che ti dirà tutto in una volta perché la seguente influenza sul tipo di test che dovresti eseguire:
E così via.
Ecco un breve elenco di strumenti con il più semplice da eseguire nella parte superiore e difficile / più approfondito / meglio vicino alla parte inferiore:
Greg: ottieni il codice FIO di Jens. Fa le cose bene, inclusa la scrittura di contenuti pseudo-casuali effettivi, il che mostra se il disco esegue qualche "de-duplicazione" (aka "ottimizza per i benchmark):
[ https://github.com/axboe/fio/ ]
Qualcos'altro è sospetto: dimentica Bonnie o altri strumenti tradizionali.
Fonte: commento lasciato su Google Plus a Greg Kroah-Hartman di Linus Torvalds .
Se non ti preoccupi di leggere tutto ciò, ti consiglio solo lo strumento IOPS . Ti dirà la velocità del mondo reale a seconda della dimensione del blocco.
Altrimenti, quando faccio un benchmark IO osserverei le seguenti cose:
Utilizzo della CPU
Quale dimensione di blocco utilizzerai : se vuoi leggere / scrivere 1 GB da / su disco, questo sarà rapido se esegui un'operazione di I / O. Ma se la tua applicazione deve scrivere in blocchi da 512 byte su tutto il disco rigido in pezzi non sequenziali (chiamati I / O casuali anche se non è casuale), questo avrà un aspetto diverso. Ora, i database faranno di I / O per il volume di dati e sequenziale I / O per il volume della registrazione casuale a causa della loro natura . Quindi, prima di tutto devi capire cosa vuoi misurare. Se si desidera copiare file video di grandi dimensioni che è diverso rispetto a se si desidera installare Linux.
Questa dimensione a blocchi sta influenzando il conteggio delle operazioni di I / O eseguite. Se si eseguono, ad esempio, 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 la sincronizzazione diretta di IO e attendi i 512 byte prima di richiedere i successivi 512 byte. In questo caso, aumentare la dimensione del blocco è come aggiungere cache.
Inoltre, tieni presente che esiste IO sincronizzato e asincrono: con IO sincronizzato non emetterai la successiva richiesta IO prima che ritorni quella corrente. Con asincrono IO è possibile richiedere ad es. 10 blocchi di dati e quindi attendere al loro arrivo. I thread di database Disctinct in genere utilizzano IO di sincronizzazione per il registro e IO di sincronizzazione per i dati. Lo strumento IOPS si occupa di ciò misurando tutte le dimensioni dei blocchi rilevanti a partire da 512 byte.
Leggerai o scriverai : di solito leggere è più veloce della scrittura. Tuttavia, la memorizzazione nella cache funziona in un modo abbastanza diverso per le letture e le scritture:
Per le scritture, i dati verranno consegnati al controller e, se memorizzati nella cache, verranno confermati prima che i dati siano sul disco a meno che la cache non sia piena. Usando lo strumento iozone puoi disegnare splendidi grafici degli altopiani 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à. Cache notevoli sono la cache della CPU, la cache del file system del sistema operativo, la cache dell'IO Controller e la cache della memoria. Lo strumento IOPS misura solo le letture. Questo gli permette di "leggere dappertutto" e 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 diversi thread. Lo strumento IOPS ne tiene conto e legge su diversi thread.
Quanto è importante la latenza per te : guardando i database, la latenza di I / O diventa enormemente importante. Qualsiasi comando di inserimento / aggiornamento / eliminazione di SQL verrà scritto nel journal del database ("log" nel linguaggio del database) su commit prima che venga riconosciuto. Ciò significa che il database completo potrebbe essere in attesa del completamento di questa operazione IO. Qui mostro come misurare il tempo medio di attesa (wait) usando lo strumento iostat .
Quanto è importante per te l'utilizzo della CPU : la tua CPU può facilmente diventare il collo di bottiglia per le prestazioni della tua applicazione. In questo caso è necessario sapere quanti cicli di CPU vengono masterizzati per byte letti / scritti e ottimizzare in quella direzione. Questo può significare decidere a favore / contro la memoria flash PCIe in base ai risultati della misurazione. Ancora una volta lo strumento iostat può darti una stima approssimativa dell'utilizzo della CPU da parte delle tue operazioni di I / O.
Se hai installato PostgreSQL, puoi utilizzare il loro eccellente benchmark pg_test_fsync . Fondamentalmente prova le tue prestazioni di sincronizzazione della scrittura.
Su Ubuntu lo trovi qui: /usr/lib/postgresql/9.5/bin/pg_test_fsync
La cosa grandiosa è che questo strumento ti mostrerà perché gli SSD aziendali valgono $.
postgresql-contribpacchetto.
È possibile utilizzare fiolo strumento di generazione IO multithread . È confezionato da diverse distribuzioni, ad esempio Fedora 25, Debian e OpenCSW.
Lo strumento fio è molto flessibile, può essere facilmente utilizzato per confrontare vari scenari di I / O, compresi quelli simultanei. Il pacchetto include alcuni file di configurazione di esempio (vedi ad es /usr/share/doc/fio/examples.). Misura correttamente le cose, ovvero stampa anche la deviazione standard e le statistiche quantitative per alcune cifre. Ad alcuni altri strumenti di benchmarking popolari non interessa.
Un semplice esempio (una sequenza di scenari semplici: lettura / scrittura sequenziale / casuale X):
$ cat fio.cfg
[global]
size=1g
filename=/dev/sdz
[randwrite]
rw=randwrite
[randread]
wait_for=randwrite
rw=randread
size=256m
[seqread]
wait_for=randread
rw=read
[seqwrite]
wait_for=seqread
rw=write
La chiamata:
# fio -o fio-seagate-usb-xyz.log fio.cfg
$ cat fio-seagate-usb-xyz.log
[..]
randwrite: (groupid=0, jobs=1): err= 0: pid=11858: Sun Apr 2 21:23:30 2017
write: io=1024.0MB, bw=16499KB/s, iops=4124, runt= 63552msec
clat (usec): min=1, max=148280, avg=240.21, stdev=2216.91
lat (usec): min=1, max=148280, avg=240.49, stdev=2216.91
clat percentiles (usec):
| 1.00th=[ 2], 5.00th=[ 2], 10.00th=[ 2], 20.00th=[ 7],
| 30.00th=[ 10], 40.00th=[ 11], 50.00th=[ 11], 60.00th=[ 12],
| 70.00th=[ 14], 80.00th=[ 16], 90.00th=[ 19], 95.00th=[ 25],
| 99.00th=[ 9408], 99.50th=[10432], 99.90th=[21888], 99.95th=[38144],
| 99.99th=[92672]
bw (KB /s): min= 7143, max=371874, per=45.77%, avg=15104.53, stdev=32105.17
lat (usec) : 2=0.20%, 4=15.36%, 10=6.58%, 20=69.35%, 50=6.07%
lat (usec) : 100=0.49%, 250=0.07%, 500=0.01%, 750=0.01%
lat (msec) : 4=0.01%, 10=1.20%, 20=0.54%, 50=0.08%, 100=0.03%
lat (msec) : 250=0.01%
cpu : usr=1.04%, sys=4.79%, ctx=4977, majf=0, minf=11
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=262144/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=1
randread: (groupid=0, jobs=1): err= 0: pid=11876: Sun Apr 2 21:23:30 2017
read : io=262144KB, bw=797863B/s, iops=194, runt=336443msec
[..]
bw (KB /s): min= 312, max= 4513, per=15.19%, avg=591.51, stdev=222.35
[..]
Si noti che la [global]sezione presenta impostazioni predefinite globali che possono essere sostituite da altre sezioni. Ogni sezione descrive un lavoro, il nome della sezione è il nome del lavoro e può essere scelto liberamente. Per impostazione predefinita, diversi lavori vengono avviati in parallelo, quindi l'esempio sopra serializza esplicitamente l'esecuzione del lavoro con la
wait_forchiave. Inoltre, fio utilizza una dimensione del blocco di 4 KiB, che può anche essere modificata. L'esempio utilizza direttamente il dispositivo non elaborato per i lavori di lettura e scrittura, quindi assicurarsi di utilizzare il dispositivo giusto. Lo strumento supporta anche l'uso di un file / directory su filesystem esistenti.
L' hdparmutilità fornisce un benchmark di lettura molto semplice, ad esempio:
# hdparm -t -T /dev/sdz
Non è un sostituto di uno strumento di benchmarking all'avanguardia come fio, ma dovrebbe essere usato solo per un primo controllo di plausibilità. Ad esempio, per verificare se l'unità USB 3 esterna è erroneamente riconosciuta come dispositivo USB 2 (si vedrebbero quindi ~ 100 MiB / s contro ~ 30 MiB / s).
Come indicato qui , puoi usare gnome-disks(se usi Gnome).
Fare clic sull'unità che si desidera testare e fare clic su "Opzioni di partizione aggiuntive" (le ruote). Poi Benchmark Partition. Otterrai la lettura / scrittura media in MB / se i tempi di accesso medi in millisecondi. L'ho trovato molto comodo.
È un po 'rozzo, ma funziona in un attimo:
find <path> -type f -print0 | cpio -0o >/dev/null
Puoi fare alcune cose interessanti con questa tecnica, inclusa la memorizzazione nella cache di tutti i file /libe /usr/bin. Puoi anche usarlo come parte di uno sforzo di benchmarking:
find / -xdev -type f -print0 |
sort -R --from0-file=- |
timeout "5m" cpio -0o >/dev/null
Tutti i nomi di file su root vengono trovati, ordinati casualmente e copiati nella cache per un massimo di 1 minuto. L'output di cpio ti dice quanti blocchi sono stati copiati. Ripeti 3 volte per ottenere una media di blocchi al minuto. (Nota, l'operazione di ricerca / ordinamento potrebbe richiedere molto tempo, molto più a lungo della copia. Sarebbe meglio memorizzare nella cache la ricerca / ordinamento e usarla splitper ottenere un campione di file.)