Usualmente uso hdparm para 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.
Uso de dd
Yo también he usado dd también para este tipo de pruebas. Una modificación que haría al comando anterior es agregar este bit al final de su comando, ; rm ddfile .
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
Esto eliminará el ddfile después de que se haya completado el comando. ddfile es un archivo transitorio que no necesita conservar, es el archivo que dd está escribiendo a (of=ddfile ), cuando está poniendo su HDD bajo carga.
Ir más allá
Si necesita pruebas más rigurosas de sus discos duros, puede usar Bonnie++.
Referencias
- ¿Cómo usar 'dd' para comparar su disco o CPU?
- E/s de disco comparativa con DD y Bonnie++
(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 )
¿Existen métodos mejores [que dd] para [discos de referencia]?
Sí, pero tardarán más en ejecutarse y requerirán conocimientos sobre cómo interpretar los resultados; no hay un número único que le diga todo de una sola vez porque lo siguiente influye en el tipo de prueba que debe ejecutar:
- ¿Está interesado en el rendimiento de E/S aleatoria, secuencial o una combinación de las dos?
- ¿Está leyendo o escribiendo en el disco (o alguna combinación de ambos)?
- ¿Le preocupa la latencia, el rendimiento o ambos?
- ¿Está tratando de comprender cómo se comportan las diferentes partes del mismo disco duro (por lo general, las velocidades se acercan más al centro de los discos giratorios)?
- ¿Está interesado en el rendimiento de un sistema de archivos determinado al usar su disco o desea obtener resultados más cercanos al rendimiento bruto del disco al realizar operaciones de E/S directamente en 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ánta E/S está enviando (envíe muy poco de 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 comprimible es el contenido de los datos que está escribiendo (por ejemplo, los datos de solo cero son altamente comprimibles y algunos sistemas de archivos/discos incluso tienen una ruta rápida especial para datos de solo cero que conduce a números que no se pueden obtener con otro contenido)?
Y así sucesivamente.
Aquí hay una breve lista de herramientas con las más fáciles de ejecutar en la parte superior y las más difíciles/más completas/mejores más cerca de la parte inferior:
- dd (lecturas o escrituras secuenciales, solo muestra el rendimiento, se puede configurar para usar un sistema de archivos o un dispositivo de bloque, se puede configurar para omitir el caché de bloque/esperar a que la E/S se complete realmente)
- hdparm (solo lecturas secuenciales, solo muestra el rendimiento, nunca usa un sistema de archivos, se puede configurar para omitir el caché de bloque, la prueba de caché solo vuelve a leer los 2 MB iniciales)
- Punto de referencia de GNOME Disk Utility (fácil de ejecutar, nunca usa 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/fsync por muestra tamaño).
- fio (puede hacer casi cualquier cosa y brinda resultados detallados, pero requiere configuración y 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 alguna "desduplicación" (también conocida como "optimización 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.
con la herramienta IOPS
Si no puede molestarse en leer todo esto, le recomendaría la herramienta IOPS. Le indicará la velocidad real según el tamaño del bloque.
De lo contrario, al hacer un punto de referencia de IO, miraría las siguientes cosas:
- tamaño de bloque/caché/IOPS/directo frente a almacenado en búfer/asincrónico frente a sincronizado
- leer/escribir
- hilos
- latencia
-
Utilización de la CPU
-
¿Qué tamaño de bloque usarás? :Si desea leer/escribir 1 GB desde/hacia el 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 piezas no secuenciales (llamadas E/S aleatorias, aunque no es aleatoria), esto se verá diferente. Ahora, las bases de datos realizarán E/S aleatorias para el volumen de datos y E/S secuenciales para el volumen de registro debido a su naturaleza. Entonces, primero debe tener claro lo que desea medir. Si desea copiar archivos de video grandes, es diferente a si desea instalar Linux.
Este tamaño de bloque afecta el recuento de operaciones de E/S que realiza. Si lo hace, p. 8 operaciones secuenciales de lectura (o escritura, pero no mixtas), el programador de E/S del sistema operativo las fusionará. Si no es así, la memoria caché del controlador realizará 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 realizar 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 IO sincronizado y asíncrono:con IO sincronizado no emitirá la siguiente solicitud de IO antes de que regrese la actual. Con async IO puede solicitar, p. 10 fragmentos de datos y luego esperar a que lleguen. Los subprocesos de base de datos distintos normalmente usarán IO sincronizado para registro y IO asíncrono para datos. La herramienta IOPS se ocupa 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 manera bastante diferente para lecturas y escrituras:
-
Para las escrituras, los datos se entregarán al controlador y, si se almacenan en la memoria caché, los reconocerá antes de que los datos estén en el disco, a menos que la memoria caché esté llena. Usando la herramienta iozone puede dibujar hermosos gráficos de mesetas de efectos de caché (efecto de caché de CPU y efecto de caché de búfer). Los cachés se vuelven menos eficientes cuanto más se ha escrito.
-
Para las lecturas, los datos leídos se mantienen 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. Los cachés notables son el caché de la CPU, el caché del sistema de archivos del sistema operativo, el caché del controlador IO y el caché del almacenamiento. La herramienta IOPS solo medidas lee. Esto le permite "leer por todas partes" y no desea que escriba en lugar de leer.
-
-
¿Cuántos hilos 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 toma esto en cuenta y lee en varios hilos.
-
¿Qué tan importante es la latencia para ti? :En cuanto a las bases de datos, la latencia de E/S se vuelve enormemente importante. Cualquier comando SQL de inserción/actualización/eliminación se escribirá en el diario de la base de datos ("registro" en la jerga de la base de datos) en la confirmación antes de que se reconozca. Esto significa que la base de datos completa puede estar esperando que se complete esta operación de E/S. Aquí muestro cómo medir el tiempo de espera promedio (await) usando la herramienta iostat .
-
¿Qué tan importante es la utilización de la CPU para usted? :Su CPU puede convertirse fácilmente en un 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 según los resultados de la medición. De nuevo la herramienta iostat puede brindarle una estimación aproximada de la utilización de la CPU por parte de sus operaciones de E/S.