Roger Jordan Blog

Para aquellos que quieran sacar provecho de las ventajas de Drtace sin necesidad de aprender a programar D ni de tener conocimientos profundos del Kernel de OpenSolaris, podéis descargar de la web de la comunidad dtrace el Dtrace ToolKit.

Una vez descargado, disfrutaremos de una serie de scripts (actualmente 260) para poder obtener información acerca de nuestro sistema. Algunos de ellos sustituyen herramientas ya disponibles anteriormente (tipo truss, snoop, etc) que cuando las ejecutamos tienen un coste notable de recursos. En otros casos se trata de scripts que nos presentan datos que hasta ahora era complicado obtener de forma sencilla.

Para empezar a usarlo solo tenemos que descomprimir el tar que nos descargamos, hay que destacar que está perfectamente documentado, con ejemplos de cada uno de los scripts que incluye.

Por mi parte me gustaría remarcar unos pocos que, por un motivo u otro, me han llamado especialmente la atención

iotop

El nombre es auto explicativo, con el fácilmente podemos detectar el responsable de los problemas de io de nuestro sistema.

2008 Mar 31 10:17:39, load: 2.64, disk_r: 28193 KB, disk_w: 42485 KB UID PID PPID CMD DEVICE MAJ MIN D BYTES 0 2639 1 scdpmd ssd26 118 208 R 48 0 3 0 fsflush ssd22 118 183 W 512 0 3 0 fsflush ssd21 118 175 W 512 [..] 700 5828 1 oracle ssd30 118 240 W 8347648 700 5828 1 oracle did30 239 64 W 8347648

dtruss

Truss siempre ha sido una de mis herramientas favoritas, sin embargo su impacto en la performance hacía desaconsejable su uso en algunas ocasiones. Este script nos presenta la misma información, con la ventaja que su consumo de recursos es mucho menor.

bash-3.2# /opt/DTT/Bin/dtruss -eo date Mon Mar 31 02:06:13 PDT 2008 ELAPSD CPU SYSCALL(args) = return 85 60 resolvepath("/usr/lib/ld.so.1\0", 0x80476E0, 0x3FF) =12 0 28 17 resolvepath("/usr/bin/date\0", 0x80476E0, 0x3FF) = 13 0 12 3 sysconfig(0x6, 0x0, 0x1DA) = 4096 0 21 11 xstat(0x2, 0x8047FEE, 0x8047B18) = 0 0 [...]

dispqlen

Este script me ha parecido muy interesante, es muy útil para comprobar el nivel de saturación de las distintas CPUS de nuestro sistema, nos indica en cuantas ocasiones el número de procesos esperado en la cola de ejecución era de 1,2,3, etc.

bash-3.2# /opt/DTT/Bin/dispqlen.d Sampling... Hit Ctrl-C to end. ^C CPU 0 value ---- Distribution ------ count 0 | 0 0 |@@@@@@@@@@@@@@@@@@@@@@@ 12441 1 | 47 2 | 95 3 | 17 [...]

dnlcstat.d

Este script me ha llamado la atención por lo original de los datos que presenta, se trata del hit rate la caché de nombres de directorios.

root@happybox # ./dnlcstat dnlc %hit hit miss 100 4007 0 100 4077 0 100 4044 0 100 1439 0

lockbydist.d

Muchas veces se atribuyen problemas de perfomance a los bloqueos, generalmente sin ningún tipo de argumentación coherente. En este caso podemos sacar estadísticas acerca del tiempo en que cada proceso ha estado esperando por culpa de bloqueos, datos que pueden ser de mucha ayuda cuando tratemos de diagnosticar un problema de performance.

En el siguiente ejemplo vemos como sched ha estado esperando en un bloqueo en 4 ocasiones entre 32 y 65 microsegundos y una ocasión entre 16 y 32 microsegundos.

root@happybox # ./lockbydist.d > /tmp/lockstat dtrace: script './lockbydist.d' matched 1 probe crsd.bin value -------- Distribution -------- count 8192 | 0 16384 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 32768 | 0 sched value -------- Distribution -------- count 8192 | 0 16384 |@@@@@ 1 32768 |@@@@@@@@@@@@@@@@@@@@@@ 4 65536 | 0 oracle value -------- Distribution -------- count 16384 | 0 32768 |@@@@@@ 2 65536 |@@@ 1 131072 |@@@@@@@@@@@@@@@@@@@@ 7 262144 |@@@ 1 524288 | 0 1048576 |@@@@@@ 2 2097152 |@@@ 1 4194304 | 0

topsyscall

Imagino que no hace falta explicar mucha cosa, en este caso obtenemos un listado de las llamadas al sistema más ejecutadas.

Tracing... Please wait. 2008 Mar 31 12:28:11, load average: 1.95, 2.45, 2.36 syscalls: 22647 SYSCALL COUNT waitsys 67 munmap 85 fcntl 102 setcontext 117 open 138 resolvepath 153 getpid 163 lwp_sigmask 198 ioctl 199 stat 237 close 279 brk 291 mmap 329 write 349 sigaction 441 sendmsg 609 recvmsg 872 read 1101 pollsys 1398 times 14660

Si le dedicáis un rato seguro que encontrareis muchos scripts que os pueden ser de utilidad en vuestros entornos, en total son 260 (por el momento), también os podéis pasar por la página de la comunidad drtace si necesitáis obtener algún dato y no veis claro como hacerlo.

Esta semana promete para la comunidad, para empezar se celebraran dos Viernes Técnicos en el mismo día, una en Granada y otro en Madrid. Señal del interés que despierta Opensolaris.

Además se va a presentar la primera versión de la Guía del Estudiante (Community Edition), y se colgará del portal para la descarga en formato electrónico, bajo una licencia libre. Espero que el proyecto crezca y en el futuro tengamos una versión 1.1, 1.2, etc.

Por otro lado ya tenéis disponible para la descarga la presentación del Viernes Técnico correspondiente a Virtualización, en el que se trata de LDOMs, xVM, Zonas y BrandZ, dando una visión global de todas las posibilidades que ofrece en esta área Opensolaris.

Por mi parte espero veros el viernes en Madrid, para tratar de nuevo el tema de zonas. Esta vez me llevaré mi propia copia de la presentación, que ya quedé escarmentado cuando el viernes anterior me encontré dando la charla con una versión donde faltaban la mitad de cosas y el resto estaban descolocadas. Aunque no creo que esta vez Mora me deje estar dos horas haciendo experimentos, para luego tener que dar su parte de charla en 40 minutos. :)

Dtrace es una de las grandes innovaciones de OpenSolaris, permite un nivel de monitorización difícil de imaginar anteriormente sin apenas afectar al rendimiento.

Si estamos dentro de una zona, por defecto, no podremos usarlo. La seguridad de dtrace viene definida por tres privilegios dtrace_proc, dtrace_user, y dtrace_kernel. Ninguno de los tres está incluido en el set por defecto que se aplica a los procesos de una zona.

Para que el administrador de una zona pueda depurar sus aplicaciones, debemos añadir los dos primeros cuando se la configuramos.

#zonecfg:zone1>set limitpriv="default,dtrace_proc,dtrace_user"

El tercero no está permitido, ya que proporciona derechos para observar sucesos a nivel de kernel, de modo que podríamos obtener información de procesos que no pertenecen a nuestra zona, o hacer alguna trastada usando dtrace en modo destructivo (dtrace -w). De hecho si tratamos de asignarlo, nuestra zona no arrancará.

Sin embargo podemos monitorizar los eventos del kernel relacionados con nuestros procesos desde la zona Global, para ello usaremos el predicado zonename.

dtrace -n 'fbt:genunix:: /zonename == "zone1"/ { @num[probefunc] = count(); }' dtrace: description 'fbt:genunix:: ' matched 12757 probes ^C bt_gethighbit 2 bt_getlowbit 2 clear_stale_fd 2 disp_lock_exit 2 lwp_park 2 [...]

Espero veros en un par de días en el próximo Viernes Técnico.

El pasado viernes tuve el placer de participar, de forma activa, en el "viernes Técnico" que organizó la Comunidad Hispana de OpenSolaris en Madrid.

A priori no estaba prevista mi intervención, sin embargo, debido a un problema personal de uno de los conferenciantes (que le impidió asistir), me encontré frente 60 personas (aprox.), explicando que eran las zonas y como funcionaban.

Pese a los nervios, la experiencia fue grata, espero que los asistentes disfrutaran igual que yo. Además fue interesante en vistas a preparar el viernes dedicado puramente a la virtualización, ya que me permitió apreciar cuales eran los principales puntos de interés de la gente.

Por otra parte, como asistente, disfruté especialmente con la presentación de Cheeroke, un web server ligero que me dejó un grato sabor de boca y muchas ganas de probarlo en mi pequeño kurobox.

Espero que la siguiente sesión sea, si cabe, aun mejor. Nos vemos allí.