Respuestas:
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.
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
-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.
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.
Si necesita pruebas más rigurosas de sus discos duros, puede usar Bonnie ++ .
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.
hdparm+ ddo solo bonnie++o todos 3.
(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:
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:
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 .
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:
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.
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.
postgresql-contribpaquete.
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.
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).
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.
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).