Depuración de latencia de E / S de Linux

Tengo algunos problemas de E / S en un par de sistemas Linux que administro. Se manifiestan en que los procesos a menudo se bloquean durante varios segundos en llamadas al sistema simples como open (), unlink () o close () en los archivos (lo cual es un problema porque algunos de los programas involucrados necesitan una latencia de E / S bastante baja para funcionar correctamente). Es cierto que los sistemas en cuestión experimentan una carga de E / S moderada, pero difícilmente puedo pensar que sea suficiente para justificar tiempos de latencia tan enormes. A veces, las llamadas pueden tardar más de 15 segundos en completarse (aunque con mayor frecuencia pueden tomar 1 o 2 o 3 segundos más o menos).

Mi pregunta es: ¿cómo puedo averiguar por qué sucede esto? Lo que me gustaría es alguna herramienta que pueda decirme en qué están bloqueados los procesos en cuestión en el kernel, y por qué está ocupado lo que están durmiendo, qué está sucediendo con él y esas cosas. ¿Existe tal herramienta o hay alguna otra forma de tratar de depurar lo que sucede?

Alternativamente, por supuesto, si tiene alguna idea de lo que realmente está sucediendo, ¿cómo se puede evitar?

Para el registro, el sistema de archivos que uso es XFS.

Ahora, a su debido tiempo, he logrado resolver esto yo mismo, por lo que al menos puedo seguirlo yo mismo para la posteridad.

Desafortunadamente, perdí el problema original en una actualización del kernel, pero obtuve uno nuevo, aún peor en rendimiento, e igual de difícil de localizar. Las técnicas que encontré fueron las siguientes:

En primer lugar, blktrace/ blkparsees una herramienta que encontré bastante útil. Permite el seguimiento del progreso de las solicitudes de E / S individuales con muchos detalles útiles, como el proceso que envió la solicitud. Es útil poner la salida tmpfs, para que el manejo del almacenamiento de la traza no comience a rastrearse.

Sin embargo, eso ayudó solo hasta ahora, así que compilé un núcleo con más funcionalidad de depuración. En particular, encontré ftracebastante útil, ya que me permitió rastrear el proceso de bajo rendimiento dentro del espacio del kernel, para ver qué hacía y dónde se bloqueaba. Compilar un núcleo de depuración también proporciona WCHANresultados de trabajo ps, lo que puede funcionar como una forma más fácil de ver qué está haciendo un proceso dentro del núcleo, al menos para casos más simples.

También esperaba que LatencyTop fuera útil, pero lo encontré bastante defectuoso, y también que solo mostraba razones de latencia que eran demasiado "de alto nivel" para ser realmente útiles, desafortunadamente.

Además, me pareció más útil que iostatsimplemente ver el contenido de /sys/block/$DEVICE/stata intervalos muy cercanos, simplemente así:

while :; do cat /sys/block/sda/stat; sleep .1; done

Consulte Documentation/iostats.txten el árbol de fuentes del núcleo el formato del statarchivo. Verlo a intervalos cercanos me permitió ver el tiempo exacto y el tamaño de las ráfagas de E / S y esas cosas.

Al final, descubrí que el problema que tuve después de la actualización del kernel fue causado por páginas estables , una característica introducida en Linux 3.0, que, en mi caso, Berkeley DB se detuvo por períodos prolongados cuando ensuciaba páginas en su mmap'ed archivos de región. Si bien parece posible parchear esta característica, y también que los problemas que causa pueden solucionarse en Linux 3.9, he resuelto el peor problema que tenía por ahora parcheando Berkeley DB para permitirme colocar sus archivos de región en un directorio diferente (en mi caso /dev/shm), lo que me permite evitar el problema por completo.

Según mi experiencia, la herramienta estadística más simple y detallada que puede instalar para rastrear misteriosos problemas de rendimiento del sistema es http://freecode.com/projects/sysstat aka. sar

seguro que desea ver también la salida del comando iostat, especialmente cuánto es su% iowait debe estar por debajo del 5-10% bajo la carga normal del sistema (por debajo de 1.0 más o menos).

mire la salida ps si en la columna STAT ve estados D que significa que esos procesos están bloqueados y esperando IO, muy probablemente un problema de hardware con el controlador o el disco, verifique las estadísticas SMART, así como dmesg y syslog para obtener pistas

compruebe el registro sar e identifique las horas pico si alguna vez sucede esto e intente hacer coincidir esos tiempos con trabajos cron intensivos en disco, por ejemplo, copias de seguridad a través de la red

puede comparar el rendimiento de su disco con bonnie ++

Pensé en mencionar strace a pesar de que esta pregunta ahora tiene meses. Puede ayudar a alguien con un problema similar que encuentre esta página.

tratar.

strace "application"

también puedes hacer

strace -e read,write "application"

para mostrar solo eventos de lectura / escritura.

La aplicación se cargará normalmente (aunque es un poco más lenta de iniciar) y puede usarla normalmente para desencadenar el problema. La salida aparecerá en el shell que usó para iniciar strace.

Lo bueno de strace es que puede ver la función / llamada del núcleo más reciente en el momento en que la aplicación activa la desaceleración. Puede descubrir que si sus /homecuentas están en NFS, la aplicación está teniendo algunas dificultades con la E / S de archivos a través de NFS por alguna razón.