☰

Análisis del tráfico de E/S del disco

tag-icon • tag-icon ubuntu software-raid performance io
Análisis del tráfico de E/S del disco

Estoy ejecutando un servidor web (Ubuntu 11.04) que muestra un alto tráfico de escritura inesperado. Cuando se supone que el servidor no debe escribir nada, la cantidad de tráfico de escritura es comparable al tráfico de lectura.

Preocupado por operaciones de escritura innecesarias, intenté analizar qué estaba fallando en el sistema. Puedo excluir registros pesados ​​de Apache o problemas de tiempo de acceso (usandono hay tiempoconfiguración de montaje).

Para localizar el problema, quería ver qué archivos estaban escritos. Por lo tanto, habilité el inicio de sesión de IO a través de block_dump (entrada de blog útil sobre este tema:piñón.io). Cada actividad del sistema de archivos se registrará en syslog. Aquí un breve extracto de mi sistema:

21 de agosto 18:22:55 kernel xxxxx: [3984721.590864] apache2(2761): LEER bloque 1098502400 en md2 (8 sectores)
21 de agosto 18:22:55 kernel xxxxx: [3984721.594005] kjournald(316): ESCRIBIR bloque 2224394648 en md2 (8 sectores)
21 de agosto 18:22:55 kernel xxxxx: [3984721.594029] md2_raid1(260): ESCRIBIR bloque 2925532672 en sdb3 (8 sectores)
21 de agosto 18:22:55 kernel xxxxx: [3984721.594044] md2_raid1(260): ESCRIBIR bloque 2925532672 en sda3 (8 sectores)
21 de agosto 18:22:55 kernel xxxxx: [3984721.644244] apache2(2761): LEER bloque 2242118744 en md2 (8 sectores)

Ok, ahora sé qué bloques se escribieron. Pero, ¿hay alguna manera de identificar realmente los nombres de archivos que se escribieron en función de estos identificadores de bloque?

¡Gracias por tu ayuda!

Por cierto: estoy usando un Software Raid, podría ser parte del problema.

Respuesta1

Suponiendo ext2/ext3/ext4, comience con

[406420.877412] vi(12496): READ block 4522288 on dm-1 (8 sectors)

Determine el tamaño del bloque del sistema de archivos:

# /sbin/dumpe2fs /dev/dm-1 | grep 'Block size'
dumpe2fs 1.42.3 (14-May-2012)
Block size:               4096

Suponiendo que tiene una unidad con sectores de 512 bytes, divida el bloque entre 4096/512, es decir, 8 para obtener 565286.

En debugfsuso una combinación de ichecky ncheck:

debugfs:  icheck 565286
Block   Inode number
565286  142506

debugfs:  ncheck 142506
Inode   Pathname
142506  /etc/security/time.conf

Editar: haga esto en los dispositivos md*, no en los dispositivos sd*. La E/S del dispositivo sd* es el resultado de una incursión de software.

Respuesta2

El sistema de archivos reside en un nivel de abstracción más alto que los dispositivos de bloque y los RAID de software. Dicho esto, el software RAID no es parte del problema con un 99,9% de probabilidad, es solo un dispositivo de bloque. Por lo tanto, debería utilizar otro conjunto de herramientas para analizar su actividad de E/S. Recomendaría comenzar iotopidentificando primero al escritor principal entre los procesos en ejecución. Luego podrá utilizar lsofe straceidentificar en qué archivos se están escribiendo.

Respuesta3

Linux tiene un sistema de kernel llamadoinotificarpara observar cualquier cambio en un archivo. En el país de usuario, se puede utilizar elherramientas-inotify( apt-get install inotify-tools) para ver un directorio. Sin embargo, cada archivo debe tener una vigilancia individual. Puede aplicarlos de forma recursiva a un directorio (incluso a la raíz), pero cuanto menos mire, menos gastos generales habrá.

Otras opciones para reducir las cosas incluyen:

  • atoplo que le permitirá ver qué procesos están realizando escrituras
  • auditctlque tiene una sintaxis muy arcana, pero permite colocar vigilancia en cualquier llamada del sistema

información relacionada