Roger Jordan Blog

En muchas ocasiones me he encontrado procesos oracle con un alto consumo de CPU que prácticamente solo están ejecutando la llamada al sistema pollsys, la salida a un truss muestra tal que:

box# truss -faelid -c -p 12564 ^C syscall seconds calls errors read .000 2 write .000 2 times .000 47 yield .000 145 pollsys 6.568 1335638 -------- ------ ---- sys totals: 5.569 1335834 0 usr time: 35.453 elapsed: 70.540

La llamada pollsys se usa para ver si hay nuevos datos disponibles en un file descriptor, vamos a comprobarlo:

box# truss -faelid -v pollsys -p 12564 [...] 7219/1: 0.0193 pollsys(0xFFFFFFFF7FFF21D0, 2, 0xFFFFFFFF7FFF2110, 0x00000000) = 1 7219/1: fd=8 ev=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND rev=POLLIN|POLLRDNORM [...] box#pfiles 12564 [...] 8: S_IFSOCK mode:0666 dev:298,0 ino:49586 uid:0 gid:0 size:0 O_RDWR|O_NDELAY FD_CLOEXEC SOCK_DGRAM SO_SNDBUF(65536),SO_RCVBUF(131072) sockname: AF_INET 172.16.xxx.xxx port: 5884 [...]

Nuestro proceso oracle está ejecutando la llamada pollsys sobre un socket de forma continua, ¿por qué?, ¿que datos está esperando?.

La respuesta la encontré en el blog de Tanel Poder. Para resumir, Oracle está comprobando continuamente que el usuario no pulse un "ctrl+break" para abortar la consulta que ha lanzado en caso que esta sea de larga duración.

Existe el parámetro break_poll_skip en el fichero sqlnet.ora para que esta comprobación no se haga tan frecuentemente, ahorrando tiempo de CPU.

Estos últimos días hemos tenido bastantes problemas de rendimiento en un nodo de un cluster de base de datos. Después de un breve análisis se observa que el tiempo de servicio de uno de los luns supera a los 200 milisegundos, con picos de hasta 300. A la vez se observa que la cpu está empleando un 30% de tiempo en tareas de kernel.

A partir de estos dos datos "los de siempre" empiezan a especular que el tiempo de consumo por parte de kernel es consecuencia de los altos tiempos de respuesta de ese lun.

Si alguien se toma la molestia de leer algo de documentación enseguida verá que mientras un proceso espera datos de una operación de i/o está durmiendo. Esto es fácilmente observable con el comando prstat -m, veremos la columna SLP (donde se incluye el tiempo de espera para operaciones de i/o) muy cercana al 100%. Un proceso dormido no consume cpu ... saquen pues sus propias conclusiones.

El problema que se me planteó es demostrar con datos objetivos que realmente es así, para ello he recurrido a dtrace y he hecho un script que calcula cuanto tiempo de cpu ha consumido cada llamada al sistema, es decir se han empleado 13212600 nanosegundos ejecutando la llamada waitsys, 29667600 ejecutando send, etc. Con esos datos y un poco de ayuda de una hoja de calculo es fácil ver que porcentaje de tiempo de sistema se está usando en cada una.

Como curiosidad el resultado fue que el 60% de tiempo de kernel no estaba relacionado directamente con operaciones de i/o.

Desde hace unos pocos días está disponible la sección software en el menú superior de la web. Aunque ahora se encuentra prácticamente vacía, poco a poco la iremos llenando de pequeñas utilidades que nos ayudan cuando tenemos que diagnosticar algún problema de rendimiento.

Si os fijáis he dicho 'iremos', mi idea es que cualquiera pueda colaborar enviando aquel script, programita en D, lo que sea, que considere que puede ser útil a la gente y no le importe compartirlo. No hace falta decir que todo tendrá los correspondientes créditos al autor.

También hay que aclarar que el software es para OpenSolaris, esto quiere decir que no tiene porque funcionar en Solaris 10. Es especialmente importante cuando nos referimos a Dtrace, ya que los distintos probes/providers suelen estar disponibles en Solaris algo más tarde que en OpenSolaris.

Aprovecho para dar las grácias Jose Juan Mora por colaborar con un par de scripts en perl para medir el throughput de las interfaces de red y la saturación en las cpus respectivamente.

Como comenté en la entrada anterior, en el Sun OpenCommunities Forum fue patente el gran interés por la tecnología java que existe. Así que pensé en como llamar la atención acerca de opensolaris a toda esa masa de gente, y ¡et voilà! que mejor que enseñar aquello en lo que Opensolaris sobresale.

Como resultado he escrito Java y Dtrace, un artículo explicando como podemos obtener datos de la última versión de JSE mediante Dtrace.

Entradas anteriores relacionadas:

• Revisando el Sun Opencommunities Forum
• Lentitud en el sistema en formato pdf.
  

Los próximos 18 y 19 de junio se celebrará en la Escuela Politécnica Superior de la Universidad San Pablo CEU (Boadilla del Monte, Madrid) el evento "Sun Open Communities Forum". De asistencia gratuita, el Forum está especialmente dirigido a desarrolladores y tecnólogos tanto del ámbito empresarial como universitario.

Personalmente me podréis encontrar el viernes 18 en el taller de Análisis de rendimiento que organizaremos, espero veros por allí. :)

La semana pasada vió la luz la versión en pdf de los artículos Lentitud en el sistema y para mi satisfacción el feedback fué en general muy positivo. Por si fuera poco, hablaron de él en la portada de Barrapunto.

Cosas para mejorar de cara a nuevas versiones:

• Mayor profundidad en los ejemplos, algunos son muy simples.
• Desarrollar un apartado específico para la monitorización.
• Cuidar la ortografía.

Sobre el segundo punto he empezado a trabajar, añadiendo un capítulo especifico para él, un poco básico por el momento pero tendrá más contenido en breve.

Resumiendo, grácias por vuestros comentarios y a disfrutar de las nuevas versiones futuras.

Desde hace tiempo que vengo pensando que un blog no es el formato más indicado para leer documentación técnica, he tratado de paliar sus deficiencias manteniendo un menú específico para los artículos y recientemente otro exclusivamente para la serie "Lentitud en el sistema", aun así su lectura ordenada y su consulta en caso de necesidad es más complicada de lo ideal.

Para compensar todas estas deficiencias he creado un pdf con casi todo el contenido técnico de la web, intentando darle un orden coherente y un formato común a todos los artículos.

Todavía quedan muchas cosas por mejorar, además de añadir más contenido, pero ya está disponible la primera versión. Agradecería cualquier tipo de comentario que me permita mejorarlo en las sucesivas versiones.

Vergüenza me da tener el blog sin actualizar durante tanto tiempo, pero entre unas cosas y otras últimamente tengo poco tiempo libre.

Así pues aunque todavía es solo un esbozo de lo que pretendo sea el artículo final os presento analizando un proceso de la serie Lentitud en el sistema. En posteriores revisiones iré completándolo con más contenido.

¡¡¡Felices fiestas a todos !!!

En esta ocasión presento una reedición del artículo original acerca de bloqueos. Lo he expandido y adaptado al formato de la serie "Lentitud en el sistema".

Los bloqueos es un tema complejo, de diagnóstico difícil y que en muchas ocasiones se suelen usar de excusa cuando la gente no tiene ni idea de lo que está pasando. Frecuentemente será un tema de roces entre departamentos tanto cuando tengáis que argumentar que son un problema como cuando los existentes sean perfectamente normales.

Espero que encontréis útil el nuevo artículo. El feedback de cualquier tipo es bienvenido.

Nueva entrega de Lentitud en el sistema, en esta ocasión analizamos los problemas de rendimiento derivados de una i/o excesiva. Tenéis el artículo aquí.

También he rehecho un poco los menús del blog, creando una sección específica para esta serie.

Espero que sea de vuestro agrado. Cualquier feedback será agradecido.

Después de una buena temporada de sequía seguimos con la serie Lentitud en el sistema. En este artículo tratamos de explicar como diagnosticar un agotamiento de memoria libre.

Si mis obligaciones como futuro padre primerizo me lo permiten espero recuperar un buen ritmo de publicación en breve.

Seguimos con la serie "Lentitud en el sistema", ahora profundizamos un poco en la saturación de las CPUs. Se trata de unas pocas pautas para reconocer cuando el cuello de botella de nuestro sistema son los procesadores.

Podéis leer el artículo completo aquí.

Poco a poco espero ir ampliando el número de artículos de la serie, hasta cubrir los aspectos más importantes para diagnosticar el motivo de una perdida de performance.

Este es el primero de una serie de artículos que pretenden ayudar a los administradores de sistemas noveles frente a problemas de rendimiento.

Posiblemente sea una de las tareas más complejas a la que nos debemos enfrentar, no suele haber un error fácilmente localizable en el equipo, sin embargo las aplicaciones se arrastran.

Si la complejidad técnica no es suficiente, normalmente suele ir acompañada de la falta de colaboración por parte de los diversos equipos involucrados, muchas veces más interesados en escurrir el bulto que en encontrar una solución.

Esta primera entrega trata acerca de los primeros minutos después de haber recibido la incidencia, dando unas pocas pautas a seguir para hacernos una idea global del estado del sistema. En capítulos posteriores iremos viendo las distintas opciones técnicas para dar con la raíz del problema.

OpenSolaris: Lentitud en el sistema, la llamada.

Normalmente cuando un sistema se queda sin memoria física disponible empieza a "swappear". Si la escasez de memoria es realmente grabe podemos llegar a agotar la swap.

Con los recursos de los que disponen los equipos actuales es una situación poco probable, si llegamos a ella posiblemente sea debido a un bug de alguna aplicación que le lleva a consumir grandes cantidades de memoria sin liberarla. (Dada la calidad del software actual quizás no sea tan poco probable al fin y al cabo)

Cuando la swap está agotándose el sistema saca de ella las páginas que corresponden a procesos que están durmiendo. La cantidad de procesos que han sido "swapped-out" es indicada por la columna w del comando vmstat.

kthr memory page disk faults cpu r b w swap free re mf pi po fr de sr 2m m0 m1 m2 in sy cs us sy id 1 0 105 27444512 522824 298 3676 480 2237 2240 45904 2693 0 19 12 13 23541 1385668 10032 72 22 6

Una vez solventado el problema de escasez de recursos las páginas correspondientes a estos procesos no serán puestas en memoria hasta que despierten, cosa que puede suceder horas o incluso días después. Y, siendo sinceros, a quien no lo ha picado la curiosidad para saber de que procesos se trata. El siguiente comando para mdb nos los listará:

#lista los nombres de los procesos mdb -k <<EOF
::walk thread myvar|::print kthread_t t_schedflag|::grep .==0|::eval <myvar=K|::print kthread_t t_procp->p_user.u_comm
EOF
#lista los pids, hay que convertir el resultado a decimal mdb -k <<EOF
::walk thread myvar|::print kthread_t t_schedflag|::grep .==0|::eval <myvar=K|::print kthread_t t_procp->p_pidp->pid_id
EOF
#Puedes convertir de hexadeciamal a decimal en la misma shell de esta forma: # echo $((16#2A)) 42

Hace unos días escribí una pequeña introducción al uso de dtrace para diagnosticar problemas de I/O, en ella veíamos algunos ejemplos de "one liners " que nos pueden ser útiles en esta labor.

Sin embargo el administrador de sistemas puede no tener el conocimiento, o el tiempo necesario, para programar en D los scripts adecuados para obtener los datos que necesita. Aun así, afortunadamente, no tenemos que renunciar a la potencia de Dtrace ya que el Dtrace Toolkit (ver mini review) incluye varios ya hechos que muy posiblemente se adaptarán a nuestras necesidades, por lo que bastará con ejecutarlos para empezar a obtener información.

• rwtop: Tremendamente útil, nos lista los procesos accediendo a disco ordenado por la cantidad de bytes escritos/leídos.
• iotop: Muy parecido al anterior, aunque algo mas completo ya que incluye información acerca del dispositivo al que están accediendo los procesos.
• iosnoop: saca un listado con los paths de los ficheros a los que están accediendo los distintos PIDs.
• iofile.d: Parecido al anterior pero incluye un contador con lo que podemos calcular el tiempo que ha tardado cada acceso.
• bitesize: Original por los datos que presenta, vemos el tamaño de las distintas operaciones de I/O de nuestro sistema, puede ser útil a la hora de diseñar nuevos sistemas de archivos.