Como ya se anunció hace unos días la comunidad OpenSolaris va a celebrar una serie de charlas técnicas para dar a conocer las distintas características del sistema operativo. Entre ellas se cuenta una charla sobre Zonas que Mora y un servidor vamos a impartir.
Cuando tienes que hablar en público la mejor forma de ir tranquilo es teniendo un conocimiento profundo sobre el tema que vas a tratar, con ese propósito me puse a leer el capítulo que Richard y Jim dedican a las zonas en su libro Solaris Internals y a repasar los estupendos comentarios que han dejado los desarrolladores en el código fuente.
A medida que leía fuí tomando una serie de apuntes, me pareció que podrían ser interesantes para la gente así que finalmente he decidido organizarlos, darles un poco de formato y
publicarlos en forma de artículo.Espero que sea de vuestro agrado.
Los viernes 29 de Febrero, 28 de Marzo y 25 de Abril se van a realizar una serie de charlas técnicas en las instalaciones de SUN de la calle Serrano Galvache 56, Madrid.
El objetivo es dar a conocer OpenSolaris y algunas de las tecnologías que nos brinda, como Brandz, Zonas, ZFS, etc. esperemos de forma amena e interactiva.
El evento me afecta de forma directa ya que voy a colaborar en la preparación de una de ellas. Espero que el resultado este a la altura de la ilusión y cariño que ponemos al prepararla.
Desde luego cualquier sugerencia que queráis hacer es bienvenida.
Tenéis la información completa en el Portal Hispano de OpenSolaris.
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:
Estos datos pueden ser de una gran ayuda para que nuestros desarrolladores mejoren la performance de sus aplicaciones.
En el trataremos de dejar claro los distintos campos que aparecen y daremos algún patrón para poder detectar problemas en nuestro equipo. Espero que sea de vuestro agrado.
Bloqueos, interbloqueos, contención, ... palabras que se suelen usar frecuentemente cuando vemos que una aplicación o todo el sistema va lento y no sabemos porque.
Cuando nos empezamos a sumergir en el mundo del tuning uno de los comandos a los que hacen referencia los manuales es el lockstat, este lista los distintos bloqueos que se han dado en nuestro sistema a lo largo de la muestra.
A priori suena estupendamente, "por fin veremos que bloquea la aplicación" el problema es que su salida es un galimatías que salvo tengamos bastante experiencia no sabremos ni como empezar a interpretar.
Empezaremos una serie de mini-artículos con el objetivo de tratar de analizar esa información correctamente. Aquí tenéis la primera entrega.
Cuando un proceso que se esta ejecutando en el espacio de usuario necesita realizar una tarea que debe hacerse en área de kernel hace una llamada a sistema.
En la salida del vmstat la columna sy en el apartado faults nos indica el número de llamadas durante la muestra, es normal que las distintas aplicaciones estén generando miles de llamadas por lo que el valor en si no nos dirá nada, para poder detectar posibles problemas de performance es mejor fijarse en si existen grandes fluctuaciones o si es extraordinariamente alto.
Las llamadas a sistema son la mejor forma de tracear la actividad de un proceso, a través de ellas nos podemos hacer una idea de que es lo que está haciendo y del coste que implica para el equipo.
Tratamos todo este tema en mas profundidad en el siguiente artículo.
Seguimos mirando la salida del vmstat, la columna r nos presenta información de los threads que están en estado running, es decir, listos para ser ejecutados pero no han encontrado una CPU libre.
Este dato es un indicador excelente para determinar si hay saturación en los procesadores.
Para comprender un poco mejor lo que está sucediendo he preparado un artículo acerca de las dispatch queues.
La salida del comando vmstat es una de las mas útiles en Opensolaris para hacernos una idea del estado general del S.O., aunque por el nombre parece que nos va a reportar datos acerca de la memoria lo cierto es que también incluye información acerca de llamadas al sistema, cambios de contexto, % de cpu usado en procesos de usuario, sistema, ...
Pensaba hacer un artículo analizando cada uno de los campos, pero creo que es mucho contenido para concentrarlo en uno solo, además tardaría demasiado tiempo en preparlo y prefiero hacer actualizaciones mas frecuentes en el blog, Así pues haré una serie de mini artículos que de forma separada irán explicando la información que aparece en el vmstat. En
el primero trataremos los cambios de contexto.Opensolaris incluye el comando nice para ser compatible con posix sin embargo es recomendable usar priocntl en su lugar, este permite establecer el valor de la “prioridad de usuario” de un thread, este dato es tomado como un factor para calcular la “prioridad global” del hilo. El valor de la “prioridad global” será el usado a la hora de situarlo en las “dispatch queues”.
Los valores de la “prioridad de usuario” para un thread TS pueden ir desde -60 a 60. Por defecto el limite configurado para esa clase es 0 por lo que deberemos modificarlo antes de darle mas prioridad a un proceso.
Veamoslo en un ejemplo:
root@myhost # priocntl -d -i pid 2902
TIME SHARING PROCESSES:
PID TSUPRILIM TSUPRI
2902 0 0
root@myhost # priocntl -s -m 30 -i pid 2902
root@myhost # priocntl -s -p 20 -i pid 2902
root@myhost # priocntl -d -i pid 2902
TIME SHARING PROCESSES:
PID TSUPRILIM TSUPRI
2902 30 20
La opción -m establece el limite a 30, y la opción -p pone el valor de user priority a 20.
Si quieres profundizar mas en este tema es un buen momento para leer el artículo que publicamos ayer.
Hoy tratamos acerca de las distintas scheduling classes que existen en Opensolaris. Estas definen el rango de prioridades que pode tomar un proceso a lo largo de su ciclo de vida. Aquí teneis el enlace al artículo completo.
Vuestras opiniones son bienvenidas :)
Como podéis ver, salvo alguna pequeña modificación en la hoja de estilo para hacer la web un poco mas legible, el aspecto del blog sigue siendo el de una de las plantillas por defecto. Con algo mas de tiempo iré modificandola para que tome un aire un poco mas personal.
De momento he decidido centrar mis esfuerzos en darle un poco de contenido a la web, por eso he escrito el
primer articulo. En el trataremos el funcionamiento del Page Scanner, este es un thread del kernel de Opensolaris que se activa cuando la memoria libre escasea, os invito a leéroslo y enviar cualquier feedback a mi correo. Espero que sea de vuestro agrado.