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.

Normalmente soy de los que suelo borrar los típicos correos con Power Points, videos, y demás pavadas que suele enviar la gente sin siquiera mirarlos. Solo hago dos excepciones, que sea una cámara oculta o que me llame la atención de forma especial.

En el primer de los casos no puedo evitarlo, me pirran las cámaras ocultas. Si lo sé, muchos lo considerarán un humor fácil, algunos incluso de mal gusto, puede que hasta cruel. Y debo darles la razón, pero si dijera que una buena cámara oculta me deja impasible mentiría, lo cierto es que me destornillo de risa hasta llorar a lagrimón suelto.

El segundo de los casos es sencillo de comprender, si el título del mail te hace pensar que trata sobre un tema que te interesa, te resulta curioso, etc. Lo abres, así de sencillo.

Hace unos días me llegó el enlace a un video, que muchos conocerán ya pues tiene unos meses, donde unos periodistas muestran un portátil con Windows 7 piden la opinión a la gente. Las inocentes víctimas no saben que en realidad se trata de un Linux con KDE 4.

Desde luego los comentarios de lo fácil, bonito y rápido que es no tienen precio, a juzgar por ellos migrar de Windows a Linux es cuestión sencilla.

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.
  

Este viernes pasado estuve en el Sun Open Communities Forum, lo cierto es que no puedo opinar sobre la mayoría de charlas ya que estuve casi todo el tiempo ocupado preparando mi taller, comentando cosas sobre la comunidad con los demás miembros y bromeando un rato.

La impresión que me dio es que la mayoría de gente estaba más interesada en Java y tecnologías relacionadas con la Web que no en Opensolaris. Coincide con mi opinión el hecho que la retroalimentación que he leído se centra en ese apartado, como por ejemplo Daniel Latorre o Abel Mendivil.

A pesar del menor protagonismo de OpenSolaris, un pequeño grupo de "fanáticos" aprovechamos la ocasión para disfrutar de lo lindo. La asistencia al taller de rendimiento fue modesta, aunque eso favoreció el dinamismo, siendo la interacción con los asistentes notable. Entre bromas, ejemplos y ejercicios fuimos aprendiendo a ver las tripas del sistema. Posiblemente lo que más llamó, la atención fue las posibilidades de Dtrace, mostrando como se pueden obtener datos difícilmente observables en otros *nix.

Al final de la charla el feedback de los asistentes fue muy positivo, lo que me anima a repetirla en alguna futura ocasión.

Os dejo la presentación usada para que podáis revisarla a vuestro gusto.

Gracias a todos los que hicieron posible el evento y espero veros en el siguiente.

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í. :)

En breve tengo pensado publicar una nueva capítulo de Lentitud en el sistema dedicado exclusivamente a problemas de red. Es un tema bastante complejo, ya que a menudo dependes de la colaboración de terceros.

Como parte la documentación vienen varios ejemplos de dtrace bastante útiles, de momento adelanto este, nos da el troughput actual de cada interfaz. Aviso, debido a que el provider ip se ha incorporado recientemente no funciona ni en Solaris 10, ni en versiones antiguas de OpenSolaris.

/usr/sbin/dtrace -q -n ' ip::: send { @bytes_snd[args[3]->if_name] = sum(args[4]->ipv4_length); } ip:::receive { @bytes_rcp[args[3]->if_name] = sum(args[4]->ipv4_length); } profile:::tick-1sec { printf("Enviados (bytes/seg): "); printa(@bytes_snd); clear(@bytes_snd); printf("Recividos (bytes/seg):"); printa(@bytes_rcp); clear(@bytes_rcp); } '

Entradas anteriores relacionadas:

• Lentitud en el sistema en formato pdf.
  

Si, el blog ha estado un poco abandonado últimamente, los primeros meses de un padre son bastante duros, creedme. Es una mezcla entre felicidad, satisfacción y desesperación. Pronto aprendes esa palabra nueva, cólicos, que nadie sabe explicarte muy bien en que consisten y aun menos como se curan, pero son totalmente reales.

Pasados ya estos dos primeros meses, niña y padres ya nos hemos adaptado y aprendido a comprendernos mutuamente, así que espero que después de semana santa poder ir retomando la actividad en el blog.

Os dejo una foto de mi chiquitina.

Esta tarde, teníamos poco trabajo, así que junto a los compañeros de la oficina, hemos elaborado una lista, en clave de humor, sobre aquellas verdades que todo administrador de sistemas que se precie debe tener en cuenta:

1.- El backup es para cobardes.

Para que perder el tiempo en algo que al final, nunca usas. Además si en alguna ocasión llegas a necesitarlo seguro que ese día no ha funcionado la copia.

2.- Entorno de pruebas = entorno de producción.

Aunque a todos nos gustaría tener un entorno de producción inmaculado, seguro que no te podrás librar del desarrollador mediocre que te estará pidiendo subidas cada dos por tres para solucionar sus metidas de pata.

3.- En tu próximo trabajo tampoco habrá tías buenas.

Hace falta explicación? en cuantas empresas has trabajado tú? cuantas chicas guapas había? ... pues eso.

4.- Si tienes un problema pregunta a Google.

Google es el oráculo de los dioses del binario, si el no lo sabe a quien podrás acudir? si si, dirás que llamemos al soporte técnico, pero donde crees que buscan ellos las respuestas?

5.- Si Google no sabe la respuesta tienes un problema.

Simplemente, si no está en Google no existe, si tienes algo que no existe debes estar en una paradoja temporal.

6.- Los usuarios mienten.

Es un hecho constatado ampliamente, cuantas veces he escuchado a alguien decir "no yo no he tocado nada" y tú en los logs estás leyendo "rm -rf /home/pepito".

7.- Puedes luchar contra la estupidez de los usuarios, pero no contra la de ESE usuario.

Da igual el nivel de seguridad que implementes, da igual el grado de monitorización que tengas, etc siempre habrá un zopenco que conseguirá joderlo todo.

8.- No importa lo que digan, el problema no es del sistema, es de ... (sustituye ... por lo que te de más rabia).

No hay nada como la jerga técnica para despistar a la gente sobre la fuente del problema, eso sí, recuerda que lo del condensador de fluzo está demasiado visto.

9.- Ubuntu no es sistema operativo.

Bueno vale, aceptamos pulpo, Ubuntu es un sistema operativo, pero no habéis tenido nunca ganas de mandar a paseo al último fan boy que os explica la gran novedad que incluye su africana distribución. Sin darse cuenta que cualquier otra también la tiene incorporada.

10.- Digan lo que digan, no parchees un sistema que funciona.

Si, los badpatch existen, yo los he sufrido. No hay nada más jodido y difícil de justificar que algo que funcionaba bien deje de hacerlo. Si aún así eres tan responsable como para aplicar los parches, rompe el espejo primero. !!!

Por favor que nadie se tome en serio ni uno de los apartados anteriores, son fruto de una tarde aburrida y mucha imaginación. ¿Tú también te aburres? ¿Cuales de ellas quitarías y cuales añadirías tú?