(Un chico de Windows pregunta) Medición de la latencia de disco en Linux: ¿me molesto?


11

En Windows, cada vez que quiero validar / confirmar que puede haber problemas relacionados con las E / S en un volumen en el que vive una base de datos u otra aplicación de baja latencia, verifico la latencia del disco.

Si veo el contador de transferencia / seg. De disco promedio de Windows > 18-20 ms de forma constante, mi canario en una mina de carbón acaba de morir y necesito investigar más. Drop-dead simple.

Estoy mirando Linux ahora, y no veo una métrica similar basada en la latencia. La rápida investigación que he hecho indica que quizás ni siquiera QUIERO ... Veo muchas referencias a E / S. Espere a que la mayoría de las personas rastree esto.

¿Existe una regla general que utilices con respecto a esto? Por ejemplo, ¿CUALQUIER I / o espera, veo mal para el volumen de una base de datos? ¿Existe un comando simple de iostat que me brinde una mejor visión del estado general del disco que simplemente mirar TOP?

¡Muchas gracias!


44
Puedes mirar hacia arribaioping
ewwhite

Gracias, @ewwhite. Supongo que me pregunto si necesito cambiar mi enfoque por completo y, en cambio, monitorear esto de una manera diferente, ¿sabes?
Russell Christopher

2
Habilite la colección sysstat en sus sistemas. Luego puede examinar el porcentaje de CPU iowait, que es muy útil para diagnosticar la lentitud relacionada con IO.
EEAA

2
@RussellChristopher Puede ver un ejemplo de sarsalida aquí . Presta atención a la %iowaitcolumna.
EEAA

@Matt aunque es MUY similar, el enfoque es ligeramente diferente. Ese control de calidad está más centrado en realizar pruebas en un entorno simulado, donde este Q parece ser más sobre el monitoreo del rendimiento actual en el entorno de producción.
BeowulfNode42

Respuestas:


12

Personalmente uso el comando iostat -xk 10y miro la awaitcolumna.

  • -x Muestra estadísticas extendidas.
  • -k Muestra estadísticas en kilobytes por segundo. O use m para megabytes / s.
  • 10 intervalos de visualización en segundos

Esta es una métrica prácticamente idéntica a la media de segundos de disco / transferencia de Windows y aparece en ms en lugar de segundos. Por lo tanto, se podrían aplicar reglas generales similares, aunque esto dependerá de todo tipo de cosas. Normalmente encuentro que los usuarios comienzan a quejarse a los 15 ms y 20 ms es muy malo.

Presione ctrl + c para salir, o especifique el número de iteraciones para ver con el parámetro de conteo. Tenga en cuenta que el resultado de la primera iteración está muy sesgado debido a la pequeña muestra de tiempo utilizada en la primera iteración.

De la man iostatpágina

esperar El tiempo promedio (en milisegundos) para que las solicitudes de E / S emitidas al dispositivo sean atendidas. Esto incluye el tiempo dedicado por las solicitudes en cola y el tiempo dedicado a atenderlas.

Editar: await es la métrica principal que uso para mirar un disco bajo cargas de producción para ver si su rendimiento y iops pueden mantenerse al día con la demanda.

La estadística% iowait trata más sobre el equilibrio entre el uso de la CPU y el disco. iostat% seguirá siendo menor de lo esperado, si tanto la CPU y la actividad del disco son altos. Por otro lado, comenzando con niveles de uso de disco bastante bajos,% iostat puede ser relativamente alto si la CPU está inactiva. Dicho esto en espera, también debe tomarse con un grano de sal. Si está ocurriendo una gran cantidad de lectura / escritura secuencial, sesgará la cifra a un valor inferior, y su regla general de 18 ~ 20 ms no será útil en estas condiciones porque la mayoría de los fragmentos que se escriben serán los datos secuenciales y serán atendidos por el disco muy rápidamente, mientras que el otro io aleatorio estará esperando, debido al sistema Native-Command-Command-Queuing (NCQ) integrado en el disco para optimizar el rendimiento al permitir que el disco elija la secuencia a la que se atienden las solicitudes.


Gracias @ beowulfNode42. ¿Es esta la métrica principal que utiliza en términos de mirar "disco defectuoso"? New Relic, parece centrarse en i / o de espera y el disco de utilización (lectura y escritura) porcentaje ... Esto me hace pensar que estoy persiguiendo el mal métrica, o si simplemente informar información menos útil ....
Russell Christopher

@RussellChristopher las otras estadísticas proporcionan el contexto requerido para interpretar la información de espera. por ejemplo, si hay muchos iops (r / yw / s), muchos MB / s, es el tamaño de solicitud promedio (avgrq-sz) grande o pequeño, y cuál es el tamaño promedio de la cola (avgqu-sz). Sí, junto con las métricas relacionadas con la CPU% iowait,% user,% system, etc. para ver si el disco está ralentizando la CPU o viceversa.
BeowulfNode42
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.