¿Cómo puedo comparar mi HDD?

51

He visto comandos para comparar el disco duro de uno como este usando dd:

$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"

¿Hay mejores métodos para hacerlo que esto?

slm
fuente
relacionado: askubuntu.com/questions/87035/…
Ciro Santilli 新疆 改造 中心 法轮功 六四 事件

Respuestas:

62

Usualmente uso hdparmpara comparar mis discos duros. Puede comparar tanto las lecturas directas como las lecturas en caché. Querrá ejecutar los comandos un par de veces para establecer un valor promedio.

Ejemplos

Aquí hay una lectura directa.

$ sudo hdparm -t /dev/sda2

/dev/sda2:
 Timing buffered disk reads: 302 MB in  3.00 seconds = 100.58 MB/sec

Y aquí hay una lectura en caché.

$ sudo hdparm -T /dev/sda2

/dev/sda2:
 Timing cached reads:   4636 MB in  2.00 seconds = 2318.89 MB/sec

Detalles

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

Usando dd

Yo también he usado ddpara este tipo de pruebas también. Una modificación que haría al comando anterior es añadir este bit para el final de su comando, ; rm ddfile.

$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile

Esto eliminará ddfiledespués de que se haya completado el comando. NOTA: ddfile es un archivo transitorio que no necesita guardar, es el archivo que ddestá escribiendo en ( of=ddfile), cuando está cargando su HDD.

Ir más allá

Si necesita pruebas más rigurosas de sus discos duros, puede usar Bonnie ++ .

Referencias

slm
fuente
1
También me gusta hdparm, para puntos de referencia rápidos. El único inconveniente es que solo mide el ancho de banda de lectura y el rendimiento de muchos tipos de dispositivos de bloque (por ejemplo, RAID, iSCSI) puede ser muy asimétrico. Para comparar el rendimiento 'antes' y 'después' en el mismo cuadro, ddtambién funciona bien.
Alexios
@Alexios: sí, gracias por mencionar eso. Sí, normalmente tiene que usar al menos hdparm+ ddo solo bonnie++o todos 3.
slm
En lugar de sincronizar, lo cual es cuestionable, use iflag = direct oflag = direct cuando se supone (por ejemplo, linux con un sistema de archivos que admite io directo).
22

(Esta es una pregunta muy popular: puede ver variaciones en https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 y https://askubuntu.com/q / 87035/740413 )

¿Hay mejores métodos [que dd] para [discos de referencia]?

Sí, pero tardarán más en ejecutarse y requieren conocimiento sobre cómo interpretar los resultados; no hay un número único que le diga todo de una vez porque lo siguiente influye en el tipo de prueba que debe ejecutar:

  • ¿Está interesado en el rendimiento de E / S que es aleatorio, secuencial o una combinación de ambos?
  • ¿Estás leyendo o escribiendo en el disco (o alguna mezcla de los dos)?
  • ¿Le preocupa la latencia, el rendimiento o ambos?
  • ¿Está tratando de entender cómo funcionan las diferentes partes del mismo disco duro (generalmente se acelera más cerca del centro de los discos giratorios)?
  • ¿Está interesado en cómo funcionará un determinado sistema de archivos cuando use su disco o desea resultados más cercanos al rendimiento bruto del disco al hacer E / S directamente a un dispositivo de bloque?
  • ¿Está interesado en cómo funciona un tamaño particular de E / S?
  • ¿Está enviando la E / S de forma síncrona o asíncrona?
  • ¿Cuántas E / S está enviando (envíe muy poco de la manera incorrecta y toda la E / S podría almacenarse en caché para que termine probando la velocidad de su RAM en lugar de la velocidad del disco)?
  • ¿Qué tan compresible es el contenido de los datos que está escribiendo (por ejemplo, los datos de solo cero son altamente compresibles y algunos sistemas de archivos / discos incluso tienen una ruta rápida especial para datos de solo cero que conducen a números que no se pueden obtener con otro contenido)?

Y así.

Aquí hay una breve lista de herramientas con las más fáciles de ejecutar en la parte superior y difíciles / más completas / mejores más cerca de la parte inferior:

  1. dd (las lecturas o escrituras secuenciales, solo muestra el rendimiento, se pueden configurar para usar un sistema de archivos o un dispositivo de bloque, se pueden configurar para omitir el caché de bloque / esperar a que la E / S se complete realmente)
  2. hdparm (solo lecturas secuenciales, solo muestra el rendimiento, nunca usa un sistema de archivos, se puede configurar para omitir el bloque de caché, la prueba de caché solo vuelve a leer los 2 MBytes iniciales)
  3. El punto de referencia de GNOME Disk Utility (fácil de ejecutar, nunca utiliza un sistema de archivos, gráfico, pero requiere una instalación completa de GNOME, proporciona números de latencia y rendimiento para diferentes tipos de E / S, pero la carga de trabajo de escritura en realidad está haciendo lectura / escritura / sincronización por tamaño de muestra).
  4. fio (puede hacer casi cualquier cosa y proporciona resultados detallados, pero requiere configuración y una comprensión de cómo interpretar dichos resultados). Esto es lo que dice Linus al respecto:

    Greg: obtén el código FIO de Jens. Hace las cosas bien, incluida la escritura de contenido pseudoaleatorio real, que muestra si el disco realiza una "desduplicación" (también conocida como "optimizar para puntos de referencia):

    [ https://github.com/axboe/fio/ ]

    Cualquier otra cosa es sospechosa: olvídate de bonnie u otras herramientas tradicionales.

Fuente: comentario dejado en Google Plus a Greg Kroah-Hartman por Linus Torvalds .

Luego
fuente
11

con la herramienta IOPS

Si no puede molestarse en leer todo esto, le recomiendo la herramienta IOPS . Le indicará la velocidad del mundo real según el tamaño del bloque.


De lo contrario, al hacer un punto de referencia IO, miraría las siguientes cosas:

  • Blocksize / cache / IOPS / direct vs buffer / async vs sync
  • leer escribir
  • hilos
  • latencia
  • Utilización de la CPU

  • Qué tamaño de bloque usará : si desea leer / escribir 1 GB desde / al disco, esto será rápido si realiza una operación de E / S. Pero si su aplicación necesita escribir fragmentos de 512 bytes en todo el disco duro en partes no secuenciales (llamadas E / S aleatorias, aunque no es aleatoria), esto se verá de manera diferente. Ahora, las bases de datos harán E / S aleatorias para el volumen de datos y E / S secuenciales para el volumen de registro debido a su naturaleza . Entonces, primero debes aclarar lo que quieres medir. Si desea copiar archivos de video grandes, es diferente de si desea instalar Linux.

    Este tamaño de bloque afecta el recuento de operaciones de E / S que realiza. Si realiza, por ejemplo, 8 operaciones secuenciales de lectura (o escritura, pero no mixtas), el planificador de E / S del sistema operativo las fusionará. Si no lo hace, la memoria caché del controlador hará la fusión. Prácticamente no hay diferencia si lee 8 bloques secuenciales de 512 bytes o un fragmento de 4096 bytes. Una excepción: si logra hacer una sincronización directa de E / S y espera los 512 bytes antes de solicitar los siguientes 512 bytes. En este caso, aumentar el tamaño del bloque es como agregar caché.

    También debe tener en cuenta que hay sincronización y sincronización de E / S: con la sincronización de E / S no emitirá la siguiente solicitud de E / S antes de que regrese la actual. Con IO asíncrono, puede solicitar, por ejemplo, 10 fragmentos de datos y luego esperar a que lleguen. Los subprocesos de base de datos Disctinct generalmente usarán IO de sincronización para el registro y IO asíncrono para los datos. La herramienta IOPS se encarga de eso midiendo todos los tamaños de bloque relevantes a partir de 512 bytes.

  • ¿Leerás o escribirás ? Por lo general, leer es más rápido que escribir. Pero tenga en cuenta que el almacenamiento en caché funciona de una manera bastante diferente para lecturas y escrituras:

    • Para las escrituras, los datos se entregarán al controlador y, si se almacenan en caché, se reconocerán antes de que los datos estén en el disco, a menos que el caché esté lleno. Usando la herramienta iozone puedes dibujar hermosos gráficos de mesetas de efectos de caché (efecto de caché de CPU y efecto de caché de búfer). Las cachés se vuelven menos eficientes cuanto más se ha escrito.

    • Para las lecturas, los datos leídos se guardan en caché después de la primera lectura. Las primeras lecturas tardan más y el almacenamiento en caché se vuelve cada vez más efectivo durante el tiempo de actividad. Las memorias caché notables son la memoria caché de la CPU, la memoria caché del sistema de archivos del sistema operativo, la memoria caché del controlador IO y la memoria caché del almacenamiento. La herramienta IOPS solo mide las lecturas. Esto le permite "leer por todas partes" y no desea que escriba en lugar de leer.

  • Cuántos subprocesos usará : si usa un subproceso ( usando dd para los puntos de referencia del disco ), probablemente obtendrá un rendimiento mucho peor que con varios subprocesos. La herramienta IOPS tiene esto en cuenta y lee en varios hilos.

  • Qué tan importante es la latencia para usted : mirando las bases de datos, la latencia IO se vuelve enormemente importante. Cualquier comando de inserción / actualización / eliminación de SQL se escribirá en el diario de la base de datos ("log" en la jerga de la base de datos) en commit antes de ser reconocido. Esto significa que la base de datos completa puede estar esperando que se complete esta operación de E / S. Muestro aquí cómo medir el tiempo de espera promedio (en espera) usando la herramienta iostat .

  • Qué tan importante es la utilización de CPU para usted : su CPU puede convertirse fácilmente en el cuello de botella para el rendimiento de su aplicación. En este caso, debe saber cuántos ciclos de CPU se queman por byte leído / escrito y optimizar en esa dirección. Esto puede significar decidir a favor o en contra de la memoria flash PCIe dependiendo de los resultados de su medición. Nuevamente, la herramienta iostat puede darle una estimación aproximada de la utilización de la CPU por sus operaciones de E / S.

Thorsten Staerk
fuente
1
El script iops es agradable, aunque estaba realmente confundido de que no estaba en apt o pip. Sin embargo, funciona.
ThorSummoner el
La herramienta iops parece estar abandonada. Además, solo mide las lecturas y no imprime ninguna estadística (por ejemplo, stddev / cuantitativas).
maxschlepzig
La herramienta iops es simple y eso es lo que necesita para lograr la comparabilidad. Básicamente es un contenedor para la llamada al sistema de lectura, hecha al azar en un archivo (todo es un archivo). Créalo o lea la fuente: está terminado y el código no necesita una actualización. Piénselo: ¿realmente quiere otra herramienta como IOMeter con miles de líneas de código donde cada una sea discutible? ¿Y qué haces con una nueva versión? ¿Tendrá que volver a hacer todos los puntos de referencia?
Thorsten Staerk
8

Si ha instalado PostgreSQL, puede usar su excelente punto de referencia pg_test_fsync . Básicamente prueba tu rendimiento de sincronización de escritura.

En Ubuntu lo encuentras aquí: /usr/lib/postgresql/9.5/bin/pg_test_fsync

Lo bueno de esto es que esta herramienta le mostrará por qué los SSD de las empresas valen el dinero extra.

Olav Grønås Gjerde
fuente
2
En Debian está disponible en postgresql-contribpaquete.
TranslucentCloud
5

Puede usar fiola herramienta de generación de IO multiproceso . Está empaquetado por varias distribuciones, por ejemplo, Fedora 25, Debian y OpenCSW.

La herramienta fio es muy flexible, se puede usar fácilmente para comparar varios escenarios de E / S, incluidos los concurrentes. El paquete viene con algunos archivos de configuración de ejemplo (cf. ej /usr/share/doc/fio/examples.). Mide correctamente las cosas, es decir, también imprime la desviación estándar y las estadísticas cuantitativas para algunas cifras. Cosas que algunas otras herramientas de evaluación comparativa populares no les importan.

Un ejemplo simple (una secuencia de escenarios simples: secuencial / aleatoria X lectura / escritura):

$ 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 llamada:

# 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
[..]

Tenga en cuenta que la [global]sección tiene valores predeterminados globales que pueden ser anulados por otras secciones. Cada sección describe un trabajo, el nombre de la sección es el nombre del trabajo y se puede elegir libremente. Por defecto, se inician diferentes trabajos en paralelo, por lo tanto, el ejemplo anterior serializa explícitamente la ejecución del trabajo con la wait_forclave. Además, fio usa un tamaño de bloque de 4 KiB, que también se puede cambiar. El ejemplo usa directamente el dispositivo sin procesar para trabajos de lectura y escritura, por lo tanto, asegúrese de usar el dispositivo correcto. La herramienta también admite el uso de un archivo / directorio en sistemas de archivos existentes.

Otras herramientas

La hdparmutilidad proporciona un punto de referencia de lectura muy simple, por ejemplo:

# hdparm -t -T /dev/sdz

No es un reemplazo para una herramienta de evaluación comparativa de vanguardia como fio, solo debe usarse para una primera verificación de plausibilidad. Por ejemplo, para verificar si la unidad USB 3 externa se reconoce erróneamente como dispositivo USB 2 (entonces verá ~ 100 MiB / s frente a ~ 30 MiB / s).

maxschlepzig
fuente
1
Esta respuesta es esencialmente una versión diferente de la respuesta resumida unix.stackexchange.com/a/138516/134856 (pero con una sección de fio ampliada). Estoy desgarrado porque proporciona un resumen de fio, pero es bastante largo y puedes saltarte el enlace a fio.readthedocs.io/en/latest/fio_doc.html#job-file-format ...
Anon
PD: Recomiendo agregar direct = 1 a la sección global de su trabajo para evitar la memoria caché de la página de Linux y solo ver la velocidad del disco (pero dado que su profundidad de yodo es solo 1 ... [inserte una discusión sobre el envío de E / S de disco] ) También es más fácil usar Stonewall ( fio.readthedocs.io/en/latest/… ) globalmente para hacer que todos los trabajos se ejecuten secuencialmente.
Anon
1

Como se señala aquí , puede usar gnome-disks(si usa Gnome).

Haga clic en la unidad que desea probar y haga clic en "Opciones de partición adicionales" (las ruedas). Entonces Benchmark Partition. Obtendrá lectura / escritura promedio en MB / sy tiempos de acceso promedio en milisegundos. Eso me pareció muy cómodo.

Sören
fuente
1

Es un poco crudo, pero esto funciona en un apuro:

find <path> -type f -print0 | cpio -0o >/dev/null

Puede hacer algunas cosas interesantes con esta técnica, incluido el almacenamiento en caché de todos los archivos /liby /usr/bin. También puede usar esto como parte de un esfuerzo de evaluación comparativa:

find / -xdev -type f -print0 | 
sort -R --from0-file=- | 
timeout "5m" cpio -0o >/dev/null

Todos los nombres de archivo en la raíz se encuentran, se ordenan aleatoriamente y los copian en la memoria caché durante un minuto. La salida de cpio le dice cuántos bloques se copiaron. Repita 3 veces para obtener un promedio de bloques por minuto. (Tenga en cuenta que la operación de búsqueda / clasificación puede llevar mucho tiempo, mucho más que la copia. Sería mejor almacenar en caché la búsqueda / clasificación y utilizarla splitpara obtener una muestra de archivos).

Oteo
fuente