Roger Jordan Blog

4.- La I/O

Los problemas de i/o siempre han sido complejos de resolver. Normalmente después de lanzar un iostat detectamos que alguno de los dispositivos de nuestro sistema tiene un throughput muy elevado, y un % de busy alto. La conclusión es evidente, algún proceso está generando muchas escrituras o lecturas sobre ese file system.

Sin embargo llegados a este punto seguir avanzando suele ser difícil, generalmente diagnosticamos de forma indirecta, es decir, si en esa partición están los datafiles de oracle, el problema será de las BB.DD., si el proceso x tiene un sleep time elevado estará escribiendo en ese dispositivo, etc.

Sin embargo con el provider io de dtrace se ha abierto un nuevo abanico de herramientas para realizar un diagnóstico de forma directa, es decir, ver directamente la cantidad de bytes escritos por un proceso, sobre un fichero, etc. Además gracias al Dtrace ToolKit, herramienta que cualquier sysadmin que se precie debe tener instalada, nos será más fácil de usar.

Nuestro objetivo

Como siempre, localizar el origen de la perdida de performance. En este caso trataremos de discernir que aplicación es la responsable del aumento de la I/O.

Reconociendo los problemas de I/O.

El Usuario

En general percibirá una perdida de velocidad en sus aplicaciones, en esta ocasión difícilmente nos proporcionará algún tipo de descripción que ayude.

Los síntomas

iostat

La forma más sencilla para comprobar si tenemos problemas de i/o es dejar lanzado unos segundos el comando iostat. Este tiene varios flags que modifican la presentación de los datos por la pantalla, cualquiera de ellos nos sirve, es cuestión de seleccionar el que nos sea más c´omodo.

root@box # iostat -xnmd 5 extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 19.3 25.2 1148.3 1438.2 0.0 0.2 0.0 3.8 0 8 2/md110 0.7 1.0 13.1 1.2 0.0 0.0 2.4 21.1 0 1 d0 (/) 0.0 0.1 1.7 1.8 0.0 0.0 4.7 8.3 0 0 d50 (/var) [...]

En las estadísticas podemos ver distintos valores, como el número de kbs escritos o leídos, número de operaciones de lectura/escritura realizadas, etc. Sin embargo estos valores absolutos no son muy fiables, dependiendo del medio físico al que estemos accediendo (scsi, fiber channel, sata, etc) pueden saturar o no el canal.

La columna %b si nos ofrece una estimación acerca de la saturación que ofrece el canal, si su valor supera un 80% de forma sostenida tendremos una seria degradación de la performance.

Asvc_t es otra columna interesante, nos indica el tiempo de latencia del dispositivo en ms. Por encima de 20 ms el usuario empieza a percibir lentitud al ejecutar sus comandos.

Al leer la salida de un iostat hay que tener en cuenta que varios file systems pueden compartir un canal de acceso, lógicamente si uno de ellos está siendo saturado por una aplicación los demás se verán igualmente penalizados.

Iostat es una buena herramienta para focalizar donde está el problema, pero no nos sirve para diagnosticar, ya que nos quedamos a nivel de dispositivo y no podemos llegar al punto de identificar un proceso culpable.

Quien está accediendo continuamente a disco

Dtrace

Desde luego dtrace es altamente recomendable para cualquier administrador de sistemas en OpenSolaris que se precie, especialmente si estamos tratando con temas de rendimiento. En el caso de la i/o es imprescindible, ya que abre un "mundo nuevo" para el diagnóstico de este tipo de problemas.

Si bien programar tus propios scripts puede ser recomendable, lo cierto es que usando los de que incluye el Dtrace ToolKit nos bastará para la mayoría de situaciones, simplificándonos el diagnóstico y ahorrándonos tiempo.

Como primer paso podemos usar iotop y rwtop, como sus nombres sugieren presentan información en un formato similar al top para procesos, de modo que es fácil identificar los responsables del elevado troughput.

Rwtop

root@box # ./rwtop Tracing... Please wait. 2008 Oct 13 16:23:43, load: 1.06, app_r: 6175 KB, app_w: 2747 KB UID PID PPID CMD D BYTES [...] 700 5828 1 oracle W 802816 700 5832 1 oracle W 1331200 700 22524 1 oracle R 5160960

iotop

root@box # ./iotop Tracing... Please wait. 2008 Oct 13 16:27:17, load: 1.11, disk_r: 9447 KB, disk_w: 6421 KB UID PID PPID CMD DEVICE MAJ MIN D BYTES [...] 700 5828 1 oracle did30 239 64 W 3571712 700 5828 1 oracle ssd30 118 240 W 3571712 700 4083 1 oracle ssd30 118 240 R 3907584 700 4083 1 oracle did30 239 64 R 3907584 700 25311 1 oracle ssd30 118 240 R 4079616 700 25311 1 oracle did30 239 64 R 4079616

Ambas herramientas nos sirven para identificar los procesos que más acceso a disco están realizando.

Con el comando pfiles podemos comprobar que file descriptors tiene abiertos un proceso en concreto.

root@box # pfiles 5828 5828: ora_dbw0_BBDD Current rlimit: 65536 file descriptors [...] 7: S_IFREG mode:0664 dev:85,40 ino:113073 uid:700 gid:701 size:269939168 O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE /opt/oracle/app/oracle/admin/BBDD/bdump/alert_BBDD.log 8: S_IFREG mode:0660 dev:85,40 ino:55179 uid:700 gid:701 size:1552 O_RDWR|O_SYNC|O_LARGEFILE /opt/oracle/app/oracle/product/10.2.0/db_1/dbs/hc_BBDD.dat [...]

Quizás sea el momento de hablar con el dba, no ?

A veces es necesario profundizar un poco más antes de echar a correr la liebre. Vamos a ver unos cuantos "one liners" de dtrace que nos pueden ser útiles para completar el diagnóstico.

# Para la prueba realizo un vi a un fichero README que está en /tmp root@box # ps -ef | grep vi root 8129 14128 0 09:53:46 pts/4 0:00 vi /tmp/README root 11121 11018 0 09:55:29 pts/6 0:00 grep vi # con el siguiente one liner podemos ver a que ficheros está # escribiendo el proceso 8129 root@box # dtrace -n ' syscall::write:entry / pid == 8129 / { @dist[fds[arg0].fi_pathname] = count(); } ' dtrace: description ' syscall::write:entry ' matched 1 probe ^C /tmp/README 8 /devices/pseudo/pts@0:4 9 # como vemos nos muestra nuestro fichero y el dispositivo de terminal. # Ahora haremos la operación inversa, es decir dado un fichero # miraremos quien está escribiendo en el, para ello he lanzado un # segundo vi al mismo archivo. root@box # dtrace -n ' syscall::write:entry / fds[arg0].fi_pathname == "/tmp/README" / { @[pid] = count(); }' dtrace: description ' syscall::write:entry ' matched 1 probe ^C 8129 8 27144 16

Las posibilidades son enormes, podemos usar syscall::reads:entry para ver las lecturas, podemos ver la cantidad de bytes escritos, etc. Es recomendable adquirir unas nociones básicas con dtrace ya que nos permitirá realizar nuestros propios scripts a medida de nuestras necesidades.

Conclusión

Gracias a dtrace ahora somos capaces de obtener información a nivel de file system, permitiéndonos identificar los procesos responsables de la carga de i/o y los archivos más accedidos.

Por favor envía cualquier comentario a roger.jordan gmail com