Roger Jordan Blog

Hacia mucho que no invertía tiempo en el motor de la web. He hecho dos modificaciones posiblemente pasarán desapercibidas para la mayoría de lectores pero que espero sirvan para mejorar el servicio.

Uno de los grandes problemas del gestor de contenido es que no puedes previsualizar, eso sumado a que partes del texto están editadas directamente con el vi hace que aparezcan muchos gazapos al publicar un artículo. Lo que he hecho es crear un servidor virtual con una copia de la web donde publicar y corregir los errores. Una vez "pasado a limpio" lo muevo a la web pública.

La segunda mejora ha sido corregir un fallo en el rss que daba problemas en las suscripciones, además he aprovechado y he creado un rss separado para la temática OpenSolaris. De este modo no invadiré con off-topics algunas webs dedicadas a este operativo. Para que los distintos webmasters NO tengan que modificar sus webs, a partir de la siguiente entrada el actual rss será solo para Opensolaris, el nuevo será para todas las categorías.

Espero que con estos cambios los lectores tengan un servicio de mejor calidad.

Veíamos en el artículo anterior que con el comando lockstat podíamos tracear los bloqueos que se dan en nuestro sistema a nivel de kernel. Sin embargo nuestra aplicación puede sufrir bloqueos a nivel de usuario. Estos se crean desde el código de una aplicación usando las llamadas mutex_init() o rwlock_init(). Lógicamente su función es sincronizar el acceso de los distintos threads a determinados recursos.

OpenSolaris nos permite tracear los dichos bloqueos con el comando plockstat, usa dtrace internamente, de forma que podemos medir el impacto en la performance. En la página man encontraremos explicadas las distintas opciones, nosotros usamos las opciones -A para que nos reporte todos los eventos, con la opción -p podemos monitorizar a un pid existente.

plockstat -A cat /etc/passwd
[...]

Mutex hold

Count     nsec Lock                         Caller

    1    70200 libc.so.1`_uberdata+0xfc0    cat`_start+0x110
    1    40900 libc.so.1`__sbrk_lock        libc.so.1`_smalloc+0x4c
    1    39400 libc.so.1`_uberdata+0x40     LM1`ld.so.1`call_init+0x70
    1    34300 libc.so.1`_uberdata+0x40	    LM1`ld.so.1`call_init+0x70
    1    27600 libc.so.1`_uberdata+0xfc0    cat`_start+0xac
    1    24700 libc.so.1`_uberdata+0x40     cat`main+0x24
    1    23100 libc.so.1`_uberdata+0x40     cat`main+0x24
    1     4900 libc.so.1`_uberdata+0xfc0    cat`_start+0xb8

La salida es casi autoexplicativa:

• Count: número de veces que se ha producido el evento
• nsec: duración media en nanosegundos del bloqueo
• Lock: nombre del bloqueo
• Caller: función mas offset que ha llamado al bloqueo.

Estos datos pueden ser de una gran ayuda para que nuestros desarrolladores mejoren la performance de sus aplicaciones.