Ahora, a su debido tiempo, logré resolver esto yo mismo, por lo que al menos puedo darle seguimiento 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 rastrear. Las técnicas que encontré fueron las siguientes:
En primer lugar, blktrace /blkparse es 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 en tmpfs , para que el manejo del almacenamiento de la traza no comience a rastrearse.
Sin embargo, eso solo ayudó hasta ahora, así que compilé un kernel con más funciones de depuración. En particular, encontré ftrace bastante útil, ya que me permitió rastrear el proceso de bajo rendimiento dentro del espacio del kernel, para ver qué hizo y dónde se bloqueó. La compilación de un kernel de depuración también proporciona WCHAN funcionales salida para ps también, que puede funcionar como una forma más fácil de ver qué está haciendo un proceso dentro del kernel, al menos para casos más simples.
También esperaba que LatencyTop fuera útil, pero lo encontré con bastantes errores, y también que solo mostraba razones de latencia que eran demasiado "de alto nivel" para ser realmente útil, desafortunadamente.
Además, lo encontré más útil que iostat para ver simplemente el contenido de /sys/block/$DEVICE/stat a intervalos muy cortos, simplemente así:
while :; do cat /sys/block/sda/stat; sleep .1; done
Ver Documentation/iostats.txt en el árbol de fuentes del kernel para el formato del stat expediente. Verlo a intervalos cercanos me permitió ver el momento exacto y el tamaño de las ráfagas de E/S y cosas por el estilo.
Al final, descubrí que el problema que tuve después de la actualización del kernel fue causado por páginas estables, una función introducida en Linux 3.0, lo que provocó que, en mi caso, Berkeley DB se detuviera durante períodos prolongados cuando ensuciaba las páginas en su mmap. archivos de región. Si bien parece posible parchear esta función, y también que los problemas que causa podrían solucionarse en Linux 3.9, resolví el peor problema que tenía por ahora al parchear Berkeley DB para permitirme colocar sus archivos de región en un directorio diferente (en mi caso /dev/shm ), permitiéndome evitar el problema por completo.
Según mi experiencia, la herramienta de estadísticas más simple y detallada que puede instalar para rastrear problemas misteriosos de rendimiento del sistema es http://freecode.com/projects/sysstat aka. sar
seguro que también desea ver la salida del comando iostat, especialmente cuánto debe estar su% iowait por debajo del 5-10% bajo una carga normal del sistema (por debajo de 1.0 más o menos).
mire la salida de ps si en la columna STAT ve estados D que significan 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 de S.M.A.R.T, así como dmesg y syslog para obtener pistas
verifique el registro sar e identifique las horas pico si esto sucede e intente hacer coincidir esas horas con trabajos cron intensivos en disco, por ejemplo, copias de seguridad en la red
puede comparar el rendimiento de su disco con bonnie++
Pensé en mencionar strace a pesar de que esta pregunta ya tiene meses. Puede ayudar a alguien con un problema similar que encuentre esta página.
prueba.
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 un poco más lento para iniciar) y puede usarla normalmente para desencadenar el problema. El resultado aparecerá en el shell que usó para iniciar strace.
Lo bueno de strace es que puede ver la llamada de función/kernel más reciente en el momento en que la aplicación activa la ralentización. Puede encontrar que si su /home las cuentas están en NFS, entonces la aplicación tiene algunas dificultades con la E/S de archivos a través de NFS por algún motivo.