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

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 [...]

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.]]> http://rjblog.es/archives/2009/10/07/T16_43_43/ http://rjblog.es/archives/2009/10/07/T16_43_43/ Wed, 07 Oct 2009 15:00:00 +0100 Roger Jordan Opensolaris 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.

]]> http://rjblog.es/archives/2009/07/14/T12_17_59/ http://rjblog.es/archives/2009/07/14/T12_17_59/ Tue, 14 Jul 2009 15:00:00 +0100 Roger Jordan Opensolaris 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.

]]> http://rjblog.es/archives/2009/07/09/T15_11_41/ http://rjblog.es/archives/2009/07/09/T15_11_41/ Thu, 09 Jul 2009 15:00:00 +0100 Roger Jordan Opensolaris 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í. :)]]> http://rjblog.es/archives/2009/01/12/T13_11_16/ http://rjblog.es/archives/2009/01/12/T13_11_16/ Mon, 12 Jan 2009 15:00:00 +0100 Roger Jordan Opensolaris 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.

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

]]> http://rjblog.es/archives/2009/01/05/T12_12_54/ http://rjblog.es/archives/2009/01/05/T12_12_54/ Mon, 05 Jan 2009 15:00:00 +0100 Roger Jordan Opensolaris 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.

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.

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.

]]> http://rjblog.es/archives/2008/10/14/T14_35_23/ http://rjblog.es/archives/2008/10/14/T14_35_23/ Tue, 14 Oct 2008 15:00:00 +0100 Roger Jordan Opensolaris 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.

]]>