Cómo comprobar 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 y velocidad de la caché. Velocidad aleatoria.
Terminal método
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/secTiming buffered disk reads: 234 MB in 3.00 seconds = 77.98 MB/secsudo hdparm -v /dev/sda también dará información.
dd le dará información sobre la velocidad de escritura.
Si la unidad no tiene un sistema de archivos (y solo entonces), utilizar 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/output10240+0 records in10240+0 records out83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/sMétodo gráfico
- >>Vaya a Sistema-Administración-Utilidad de discos.
- Alternativamente, inicie la utilidad de discos de Gnome desde la línea de comandos ejecutando
gnome-disks
- Alternativamente, inicie la utilidad de discos de Gnome desde la línea de comandos ejecutando
- Seleccione su disco duro en el panel izquierdo.
- Ahora haga clic en el botón "Benchmark-Measure Drive Performance" en el panel derecho.
- 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". Al hacer clic en el botón, se inicia la evaluación comparativa del disco duro.
Cómo comparar E / S de disco
¿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/output1024+0records in1024+0 records out402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/sSi 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 (este 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_reportingVelocidad de escritura secuencial con bloques grandes (este 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_reportingLectura aleatoria de 4K QD1 (este es el número que realmente importa para el rendimiento en el mundo real, a menos que lo sepa con certeza):
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_reportingLectura y escritura aleatoria mixta 4K QD1 con sincronización (este es el peor número de casos que debe 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_reportingAumente el --size argumento para aumentar el tamaño del archivo. El uso de archivos más grandes puede reducir los números que obtiene según la tecnología y el firmware de la unidad. Los archivos pequeños darán resultados "demasiado buenos" para los medios rotativos 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 la unidad 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 de la file no es tan importante como total de bytes escritos durante un período de tiempo corto. Por ejemplo, algunos SSD tienen un rendimiento significativamente más rápido con bloques pre-borrados o pueden tener una pequeña área de flash SLC que se utiliza como caché de escritura y el rendimiento cambia una vez que la caché SLC está llena (por ejemplo, la serie Samsung EVO que tiene una caché SLC de 20-50 GB). 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 y continuar con la prueba real inmediatamente después. Por supuesto, todo esto 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, las secuencias de prueba más cortas reflejarán mejor su rendimiento en el mundo real. Si necesita hacer mucho IO, necesita aumentar ambos --io_size y --runtime parámetros. Tenga en cuenta que algunos medios (por ejemplo, la mayoría de barato los dispositivos de destello) sufrirán de tales pruebas porque los chips de destello son lo suficientemente pobres como para desgastarse muy rápidamente. En mi opinión, si algún dispositivo es lo suficientemente pobre como para no manejar este tipo de pruebas, no debe usarse para contener datos valiosos en ningún caso. Dicho esto, no repita las pruebas de escritura grandes durante 1000 veces porque todas las celdas de memoria flash tendrán algún nivel de desgaste con la escritura.
Además, algunos dispositivos SSD de alta calidad pueden tener algoritmos de nivelación de desgaste aún más inteligentes en los que la caché SLC interna tiene suficiente inteligencia para reemplazar los datos en su lugar si se reescriben mientras los datos aún están en la caché SLC. Para dichos dispositivos, si el archivo de prueba es más pequeño que la caché SLC total del dispositivo, la prueba completa siempre escribe solo en la caché SLC y obtiene números de rendimiento más altos que los que el dispositivo puede admitir para escrituras más grandes. Entonces, para tales dispositivos, el tamaño del archivo comienza a importar nuevamente. Si conoce su carga de trabajo real, es mejor probar con los tamaños de archivo que realmente verá en la vida real. Si no conoce la carga de trabajo esperada, el uso de un tamaño de archivo de prueba que ocupe aproximadamente el 50% del dispositivo de almacenamiento debería dar como resultado un buen resultado promedio para todas las implementaciones de almacenamiento. Por supuesto, para una configuración RAID de 50 TB, hacer una prueba de escritura con un archivo de prueba de 25 TB llevará bastante tiempo.
Tenga en cuenta que fio creará el archivo temporal requerido en la primera ejecución. Se rellenará con datos pseudoaleatorios para evitar obtener números demasiado buenos de los dispositivos que intentan hacer trampa en los puntos de referencia comprimiendo los datos antes de escribirlos en el almacenamiento permanente. Se llamará al archivo temporal fio-tempfile.dat en los ejemplos anteriores y almacenados en el directorio de trabajo actual. Por lo tanto, primero debe cambiar al directorio que está montado en el dispositivo que desea probar. El fio también es compatible con el uso de medios directos como destino de prueba, pero definitivamente sugiero leer la página del manual antes de intentarlo, ya que un error tipográfico puede sobrescribir todo el sistema operativo cuando se usa el acceso directo a los medios de almacenamiento (por ejemplo, escribir accidentalmente en el dispositivo del sistema operativo en lugar del dispositivo de prueba).
Si tiene una buena SSD y desea ver números aún más altos, aumente --numjobs arriba. Eso define la concurrencia para las lecturas y escrituras. Todos los ejemplos anteriores tienen numjobs establecer en 1 por lo tanto, la prueba se trata de lectura y escritura de procesos de un solo subproceso (posiblemente con la profundidad de la cola o el conjunto QD con iodepth). Los SSD de gama alta (por ejemplo, Intel Optane 905p) deberían obtener números altos incluso sin aumentar numjobs mucho (p. ej. 4 debería ser suficiente para obtener los números de especificaciones más altos), pero algunos SSD" Empresariales & quot; requieren ir al rango 32-128 para obtener los números de especificaciones porque la latencia interna de esos dispositivos es mayor, pero el rendimiento general es una locura. Tenga en cuenta que el aumento numbjobs a valores altos por lo general aumenta la resultante rendimiento de referencia números, pero rara vez refleja el rendimiento en el mundo real de alguna manera.
No recomendaría usar /dev/urandom porque está basado en software y es lento como el cerdo. Es mejor tomar un trozo de datos aleatorios en el disco RAM. En el disco duro, la aleatoriedad no importa, porque cada byte se escribe tal cual (también en SSD con dd). Pero si probamos el grupo zfs deduplicado con datos cero o aleatorios puros, 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 deshacernos del efecto de almacenamiento en caché. Eso se puede hacer fácilmente por:
time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"con ese método se obtiene la salida:
sync ; time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync" ; rm testfile 1024+0 records in1024+0 records out104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/sreal 0m0.441suser 0m0.004ssys 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 menos que con el almacenamiento en caché.
Feliz benchmarking,
Si desea supervisar la velocidad de lectura y escritura del disco en tiempo real, puede utilizar el iotop herramienta.
Esto es útil para obtener información sobre el rendimiento de un disco para una aplicación o carga de trabajo en particular. La salida le mostrará la velocidad de lectura/escritura por proceso y la velocidad total de lectura/escritura para el servidor, similar a top.
Instalar iotop:
sudo apt-get install iotop Ejecutarlo:
sudo iotopEsta herramienta es útil para comprender el rendimiento de un disco para una carga de trabajo específica en comparación con pruebas más generales y teóricas.
Velocidad de escritura
$ dd if=/dev/zero of=./largefile bs=1M count=10241024+0 records in1024+0 records out1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/sEl 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=4k165118+0 records in165118+0 records out676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/sbonnie++ es la utilidad de referencia definitiva 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 tamaño pequeño, las actualizaciones grandes, las lecturas, las escrituras, etc. Comparar una llave USB, un disco duro (giratorio), una unidad de estado sólido y un sistema de archivos basado en RAM puede ser muy informativo para el novato.
No tengo idea de si está incluido en Ubuntu, pero puedes compilarlo desde la fuente fácilmente.
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 jamesUn poco más en: EJEMPLO SIMPLE DE BONNIE++ .
Similar question has been asked over on linux - How can I benchmark my HDD? - Unix & Linux Stack Exchange , file io - Testing IO performance in Linux - Stack Overflow and io - I/O Performance Benchmarking Linux - Server Fault .