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
-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 ++ .
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).
¿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:
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)
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)
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).
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):
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.
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.
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):
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).
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.
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:
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).
Respuestas:
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.
Y aquí hay una lectura en caché.
Detalles
Usando dd
Yo también he usado
dd
para 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
.Esto eliminará
ddfile
después de que se haya completado el comando. NOTA:ddfile
es un archivo transitorio que no necesita guardar, es el archivo quedd
está 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
fuente
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,dd
también funciona bien.hdparm
+dd
o solobonnie++
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 )
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:
Fuente: comentario dejado en Google Plus a Greg Kroah-Hartman por Linus Torvalds .
fuente
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:
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.
fuente
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.
fuente
postgresql-contrib
paquete.Puede usar
fio
la 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):
La llamada:
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 lawait_for
clave. 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
hdparm
utilidad proporciona un punto de referencia de lectura muy simple, por ejemplo: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).
fuente
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.fuente
Es un poco crudo, pero esto funciona en un apuro:
Puede hacer algunas cosas interesantes con esta técnica, incluido el almacenamiento en caché de todos los archivos
/lib
y/usr/bin
. También puede usar esto como parte de un esfuerzo de evaluación comparativa: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
split
para obtener una muestra de archivos).fuente