Roger Jordan Blog

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.

Corría el año 2000 en pleno apogeo de la burbuja de las .com, en esos años si sabias donde estaba el menú de inicio de windows eras informático y si sabias hacer un 'ls' eras administrador de sistemas *nix.

Trabajaba en una empresa que se fue pique y me lancé al mercado laboral, mi experiencia en sistemas *nix era poca, había trasteado un poco linux en mi pc, además había ido asumiendo el rol de administrador de un servidor de correo también con linux, y finalmente había estado haciendo de operador de un par de servidores NCR. Solaris por aquel entonces no lo había ni olido.

Me contrató una empresa para administrar servidores Sun en un cliente, me prometieron formación, certificaciones, ... lo que siguió fue una de las experiencias mas esperpenticas que he vivido en el ámbito laboral, el primer día me mandaron directamente al cliente, allí me encontré con el técnico que me iba a formar para posteriormente sustituirle. Me explicó los procedimientos semanales, mensuales, ... que tenía que realizar y cuatro cosillas de Solaris, a los tres días se despidió con un "ya te veo suelto" y me dejó allí solo. Quien me iba a decir a mi en ese momento que en el futuro íbamos a ser buenos amigos porque entonces me estaba acordando de toda su familia.

El día después ni corto ni perezoso me puse con mis tareas mensuales entre las cuales se incluía instalar el cluster de parches que distribuía Sun, nadie me avisó que era recomendable iniciar la máquina en single user, ni que rompiera el mirror por si algo iba mal ... así pues valientemente hice un ./install_cluster ... y ... seguidamente dejaron de funcionar todas las impresoras de la empresa.

Yo no hice nada "incorrecto", digamos que fui el brazo ejecutor pero solo seguía las instrucciones que me habían dado, aun así con 20 y poquitos años, cuarto día en un trabajo nuevo, primer día solo ... os podéis imaginar como estaba cuando me toco entrar al despacho del subdirector de informática y decirle "oye ... mira ... recuerdas todas esas impresoras ... las que se necesitan para facturación [...] bueno si, las de los usuarios también, pues mira, ... es que ... vamos que no funciona ninguna ...".

Para hacer la historia corta, al final resulto que el parche tenía un bug el cual hacia que el demonio sched no funcionara con una configuración muy concreta que por supuesto nosotros teníamos, el soporte me envió un binario temporal para salir del aprieto.

Os aseguro que ha sido una de las ocasiones en que peor lo he pasado en el trabajo, aunque el responsable de todo es aquel que decidió contratarme para un puesto para el que no estaba preparado y no se molesto ni en darme la formación adecuada para el, un ejemplo claro de como funcionaba la industria de la informática en su época dorada de las .com.

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.