Cómo verificar el rendimiento del disco duro

Cómo verificar el rendimiento de un disco duro (ya sea a través de terminal o GUI). La velocidad de escritura. La velocidad de lectura. Tamaño de caché y velocidad. Velocidad aleatoria

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.

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

Artículo

¿Hay algo más que quieras?

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

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,

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

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.

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++/

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

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 ++ .

f3 - Lucha contra el fraude flash

Compruebe la integridad, detecte unidades flash falsas y pruebe el rendimiento, las tres de una sola vez

Más sobre esta respuesta .