Cómo verificar el rendimiento del disco duro

Respuestas:

425

Método terminal

hdparm Es un buen lugar para comenzar.

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á información también.

dd le dará información sobre la velocidad de escritura.

Si la unidad no tiene un sistema de archivos (y solo entonces ), úselo of=/dev/sda.

De lo contrario, móntelo en / tmp y escriba y luego elimine el archivo de salida de prueba.

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

Método gráfico

  1. Vaya a Sistema -> Administración -> Utilidad de disco.
    • Alternativamente, inicie la utilidad de disco Gnome desde la línea de comando ejecutando gnome-disks
  2. Seleccione su disco duro en el panel izquierdo.
  3. Ahora haga clic en el botón "Benchmark - Measure Drive Performance" en el panel derecho.
  4. Se abre una nueva ventana con gráficos. Encontrarás y dos botones. Uno es para "Iniciar Benchmark de solo lectura" y otro es "Iniciar Benchmark de lectura / escritura". Cuando hace clic en el botón de cualquier persona, comienza la evaluación comparativa del disco duro.

prueba

Cómo realizar un benchmark de E / S de disco

Artículo

¿Hay algo más que quieras?

Pantera
fuente
10
Recomendaría realizar pruebas /dev/urandom, así como /dev/zeroentradas, ddcuando pruebe un SSD, ya que la compresibilidad de los datos puede tener un efecto masivo en la velocidad de escritura.
Ian Mackinnon
3
No existe tal "Sistema ->" en mi Ubuntu 12.04 Unity. O al menos no lo he encontrado. Y no veo esa herramienta de disco ni dentro de la Configuración del sistema ... O_o Pero finalmente logré ejecutarla: / usr / bin / palimpsest
Fran Marzoa
66
Tenga en cuenta que desde la 12.10 simplemente se llama Disks y se puede encontrar a través de Unity.
Paul Lammertsma
1
En Gnome, esto se ha movido a Aplicaciones -> Herramientas del sistema -> Preferencias -> Utilidad de disco. Para aquellos de uso que odian la Unidad.
Ken Sharp
2
El /tmpsistema de archivos a menudo usa un disco RAM en estos días. Por lo tanto, escribir en /tmpparece estar probando su memoria, no su subsistema de disco.
Zoredache
99

Suominen tiene razón, deberíamos usar algún tipo de sincronización; pero hay un método más simple, conv = fdatasync hará el trabajo:

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
Tele
fuente
28
Es una respuesta usando un comando / opción diferente a los demás. Veo que es una respuesta digna de una publicación propia.
Alaa Ali
2
¿Por qué has usado 384k como tamaño de bloque?
Diego F. Durán
1
@Diego No hay razón. Fue solo un ejemplo. Puedes usar cualquier otra cosa. (entre aproximadamente 4k ... 1M) Por supuesto, un tamaño de bloque más grande dará un mejor rendimiento. Y, por supuesto, disminuye el número de conteo cuando usas big bs, o tomará un año terminarlo.
Tele
no es confiable según las herramientas de referencia como iozone y los números de sysbench son mucho más bajos
MSS
1
Tenga cuidado con el uso de ceros para sus datos de escritura: algunos sistemas de archivos y discos tendrán una ruta de mayúsculas y minúsculas especiales (y otros datos comprimibles) que causarán números de referencia artificialmente altos ...
Anon
50

No recomendaría usarlo /dev/urandomporque está basado en software y es lento como el cerdo. Es mejor tomar una porción de datos aleatorios en ramdisk. En las pruebas de disco duro, el azar no importa, porque cada byte se escribe como está (también en ssd con dd). Pero si probamos el grupo zfs deduptado con cero puro o datos aleatorios, hay una gran diferencia de rendimiento.

Otro punto de vista debe ser la inclusión del tiempo de sincronización; Todos los sistemas de archivos modernos utilizan el almacenamiento en caché en las operaciones de archivos.

Para medir realmente la velocidad del disco y no la memoria, debemos sincronizar el sistema de archivos para eliminar el efecto de almacenamiento en caché. Eso se puede hacer fácilmente mediante:

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

con ese método obtienes salida:

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

entonces la velocidad de datos del disco es solo 104857600 / 0.441 = 237772335 B / s -> 237MB / s

Eso es más de 100 MB / s más bajo que con el almacenamiento en caché.

Feliz benchmarking,

Pasi Suominen
fuente
3
Tenga cuidado con el uso de ceros para sus datos de escritura: algunos discos (como SSD) y algunos sistemas de archivos tendrán una ruta de caso especial para ello. Esto da como resultado números de referencia artificialmente altos cuando se usan cero buffers. Otros patrones de datos altamente compresibles también pueden distorsionar los resultados ...
Anon
36

Si desea monitorear la velocidad de lectura y escritura del disco en tiempo real, puede usar la herramienta iotop .

Esto es útil para obtener información exacta sobre el rendimiento de un disco para una aplicación o tarea en particular. La salida le mostrará la velocidad de lectura / escritura por proceso, y la velocidad total de lectura / escritura para el servidor, muy similar a top.

Para instalar iotop:

sudo apt-get install iotop  

Para ejecutarlo:

sudo iotop
Lars
fuente
28

Si desea precisión, debe usar fio. Requiere leer el manual ( man fio) pero le dará resultados precisos. Tenga en cuenta que para cualquier precisión, debe especificar exactamente lo que desea medir. Algunos ejemplos:

Velocidad de LECTURA secuencial con bloques grandes (debe estar cerca del número que ve en las especificaciones de su unidad):

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

Velocidad de ESCRITURA secuencial con bloques grandes (debe estar cerca del número que ve en las especificaciones de su unidad):

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 read QD1 (este es el número que realmente importa para el rendimiento en el mundo real a menos que esté seguro):

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

Mezcla aleatoria 4K de lectura y escritura QD1 con sincronización (este es el peor número de caso que debería esperar de su unidad, generalmente menos del 1% de los números enumerados en la hoja de especificaciones):

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

Aumente el --sizeargumento para aumentar el tamaño del archivo. El uso de archivos más grandes puede reducir los números que obtiene dependiendo de la tecnología de la unidad y el firmware. Los archivos pequeños darán resultados "demasiado buenos" para los medios de rotación porque el cabezal de lectura no necesita moverse tanto. Si su dispositivo está casi vacío, usar un archivo lo suficientemente grande como para casi llenar el disco le dará el peor comportamiento para cada prueba. En el caso de SSD, el tamaño del archivo no importa tanto.

Sin embargo, tenga en cuenta que para algunos medios de almacenamiento, el tamaño del archivo no es tan importante como el total de bytes escritos durante un período de tiempo corto. Por ejemplo, algunos SSD pueden tener un rendimiento significativamente más rápido con bloques previamente borrados o pueden tener un área flash SLC pequeña que se usa como caché de escritura y el rendimiento cambia una vez que el caché SLC está lleno. Como otro ejemplo, los discos duros Seagate SMR tienen un área de caché PMR de aproximadamente 20 GB que tiene un rendimiento bastante alto, pero una vez que se llena, escribir directamente en el área SMR puede reducir el rendimiento al 10% del original. Y la única forma de ver esta degradación del rendimiento es escribir primero más de 20 GB lo más rápido posible. Por supuesto, todo depende de su carga de trabajo: si su acceso de escritura está lleno de retrasos prolongados que permiten que el dispositivo limpie la memoria caché interna, secuencias de prueba más cortas reflejarán mejor su rendimiento en el mundo real. Si necesita hacer muchas IO, debe aumentar ambas--io_sizey --runtimeparámetros. Tenga en cuenta que algunos medios (p. Ej., La mayoría de los dispositivos flash) recibirán un desgaste adicional de tales pruebas. En mi opinión, si algún dispositivo es lo suficientemente pobre como para no manejar este tipo de prueba, no debe usarse para contener datos valiosos en ningún caso.

Además, algunos dispositivos SSD de alta calidad pueden tener algoritmos de nivelación de desgaste aún más inteligentes donde el caché interno SLC tiene suficiente inteligencia para reemplazar los datos que se reescriben durante la prueba si llega al mismo espacio de direcciones (es decir, el archivo de prueba es más pequeño que el caché SLC total). Para tales dispositivos, el tamaño del archivo comienza a importar nuevamente. Si necesita su carga de trabajo real, es mejor probar con tamaños de archivo que realmente verá en la vida real. De lo contrario, sus números pueden parecer demasiado buenos.

Tenga en cuenta que fiocreará el archivo temporal requerido en la primera ejecución. Se rellenará con datos aleatorios para evitar obtener números demasiado buenos de dispositivos que engañan al comprimir los datos antes de escribirlos en el almacenamiento permanente. El archivo temporal se llamará fio-tempfile.daten los ejemplos anteriores y se almacenará en el directorio de trabajo actual. Por lo tanto, primero debe cambiar al directorio que está montado en el dispositivo que desea probar.

Si tiene un buen SSD y desea ver números aún más altos, aumente por --numjobsencima. Eso define la concurrencia para las lecturas y escrituras. Todos los ejemplos anteriores se han numjobsconfigurado para 1que la prueba se trate de lectura y escritura de procesos de subproceso único (posiblemente con una cola establecida con iodepth). Los SSD de gama alta (por ejemplo, Intel Optane) deberían obtener números altos incluso sin aumentar numjobsmucho (por ejemplo, 4deberían ser suficientes para obtener los números de especificaciones más altos), pero algunos SSD "Enterprise" requieren ir a 32- 128para obtener los números de especificaciones debido a la latencia interna de esos los dispositivos son más altos, pero el rendimiento general es una locura.

Mikko Rantalainen
fuente
1
Acabo de volver a probar algunos dispositivos. Utilizando la prueba de lectura secuencial anterior (tamaño de bloque de 2 MB) obtuve 280 MB / s de Samsung SSD 850 EVO y 1070 MB / s de Intel 910 SSD. Con un tamaño de bloque de 64k y una línea de comandos idéntica obtuve 268 MB / s de 850 EVO y 1055 MB / s de 910 SSD. Al menos para este tipo de dispositivos, usar un tamaño de bloque de 2 MB parece mejorar los resultados alrededor del 1-5% a pesar de que hace que el núcleo divida las solicitudes en el hardware. Supongo que incluso con las optimizaciones del kernel, la sobrecarga de enviar más syscalls es peor que la división dentro del kernel.
Mikko Rantalainen
1
Después de más pruebas, parece que obtengo el mayor rendimiento secuencial utilizando una potencia de valor 2 menor que max_sectors_kb. Cambié los comandos de ejemplo anteriores para usar un tamaño de bloque de 1 MB porque parece funcionar con hardware del mundo real. Y también probé que fsyncno importa leer.
Mikko Rantalainen
1
Dependiendo de cómo esté conectada la unidad, es posible que su profundidad de yodo sea demasiado baja. Tendrías que ver lo que Linux está enviando realmente al dispositivo y a qué profundidad lo está haciendo a ...
Anon
1
Me puse iodeptha 1para el acceso aleatorio exactamente porque los programas del mundo real a menudo corren algoritmos / lógica que no funciona con una profundidad mayor que cualquier 1. Como resultado, si dicha profundidad es "demasiado bajo" el dispositivo de E / S es malo. Es cierto que algunos dispositivos SSD se beneficiarán de una profundidad superior a 32. Sin embargo, ¿puede señalar cualquier carga de trabajo del mundo real que requiera acceso de lectura y pueda mantener una profundidad de yodo superior a 32? TL; DR: si desea reproducir un número de referencia de lectura increíblemente alto con un dispositivo de alta latencia, use iodepth=256 --numjobs=4pero nunca espere ver esos números de verdad.
Mikko Rantalainen
1
La mayoría de los programas del "mundo real" en realidad no están enviando E / S (o_) directamente y mucho menos asincrónicamente, por lo que todos nuestros ejemplos están en cargas de trabajo inusuales para superar los límites del territorio de referencia (como dicen, la mejor referencia es su carga de trabajo real). Dicho esto, hacer cosas como ejecutar múltiples máquinas virtuales ocupadas puede generar fácilmente cargas de trabajo con altas profundidades locas, pero donde la E / S a menudo parece aleatoria desde la perspectiva del disco y es un ejemplo simple de dónde puede ver una gran aceleración de cosas como NVMe. PS: Los números de ajuste demasiado alto reducirán el rendimiento por lo que hay un punto dulce ...
Anon
25

Bonnie ++ es la última utilidad de referencia que conozco para Linux.

(¡Actualmente estoy preparando un livecd de Linux en el trabajo con bonnie ++ para probar nuestra máquina basada en Windows con él!)

Se encarga del almacenamiento en caché, la sincronización, los datos aleatorios, la ubicación aleatoria en el disco, las actualizaciones de pequeño tamaño, las actualizaciones de gran tamaño, las lecturas, las escrituras, etc. Comparando una llave USB, un disco duro (rotativo), una unidad de estado sólido y un disco basado en ram El sistema de archivos puede ser muy informativo para el novato.

No tengo idea si está incluido en Ubuntu, pero puedes compilarlo desde la fuente fácilmente.

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

Corto
fuente
Bonnie tiene fallas para la evaluación comparativa de disco y puede generar fácilmente números que realmente reflejan aspectos de su sistema que no son de disco, por lo que se requiere un alto grado de cuidado si elige usarlo. Ver Brendan Gregg's Active Benchmarking: Bonnie ++ para más detalles.
Anon
22

Velocidad de escritura

$ 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

El tamaño del bloque es en realidad bastante grande. Puedes probar con tamaños más pequeños como 64k o incluso 4k.


Velocidad de lectura

Ejecute el siguiente comando para borrar la memoria caché

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

Ahora lea el archivo que se creó en la prueba de escritura:

$ 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
Limon Monte
fuente
Tenga cuidado con el uso de ceros para sus datos de escritura: algunos sistemas de archivos y discos tendrán una ruta de mayúsculas y minúsculas especiales (y otros datos comprimibles) que causarán números de referencia artificialmente altos ...
Anon
14

algunos consejos sobre cómo usar 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 poco más en: EJEMPLO SIMPLE BONNIE ++ .

nyxee
fuente