Vuelven las series

Para regocijo de los adictos a las series de TV en general, y para los no-tan-adictos pero de-baja-y-aburridos en particular ;-D, ¡comienza en serio la temporada de series en los USA!: hace un par de semanas empezó la segunda temporada de Terminator: The Sarah Connor Chronicles (tiene un pase, me ha hecho gracia ver a Shirley Manson haciendo de mala) y esta noche se emite el tercer episodio; esta noche también, estreno con DOS episodios de la tercera de Heroes (hay un resumen de las dos anteriores / presentación de la serie / propaganda pura y dura para ir calentando motores); el jueves, dos episodios también para empezar la cuarta temporada de My Name is Earl; y el domingo empieza la tercera de Dexter, aunque el primer episodio ya lo emitieron hace unas semanas.

Y hablando de series, este fin de semana que con lo de los ojos no veía muy bien (a distancia de ver la tele si) me he pegado un atracón de Firefly. No soy fan de Joss Whedon (ni Buffy ni Angel me dicen gran cosa) pero tanto Firefly como la película Serenity, su continuación, me encantan. Una pena que no se haya continuado esta serie. Si alguien no la conoce, imaginaros que el título fuera «Las aventuras de Han Solo». Pues eso, una panda de contrabandistas de poca monta liderados por un tipo duro pero carismático y con valores, que en el fondo es un pedazo de pan y al final (muy al final) siempre se pone del lado del más débil. Muy recomendable.

iostat & iotop: I/O debugging

[spanish]

Hace unos meses tuvimos un caso raro en un cliente: una aplicación no daba el rendimiento que debería, sin embargo más del 20% de CPU estaba en estado «idle» y no se había tocado la swap, por lo que no era por falta de recursos. Fijándonos mejor en los porcentajes de CPU que daba vmstat, vimos que alrededor del 30% estaba en I/O, por lo que el problema era un cuello de botella en entrada/salida.

Para averiguar la causa utilizamos dos programas:

  • iostat (viene en el paquete sysstat): similar a vmstat o ifstat, pero para operaciones de I/O. Muestra por dispositivo y por partición, cada X segundos, la cantidad de bloques leídos/escritos.
  • iotop: como el top de toda la vida, pero ordena los procesos por consumo de I/O.

Con ayuda de éstas dos utilidades es fácil detectar qué programa está causando el cuello de botella, y en qué dispositivo.

En nuestro caso, el problema era una controladora RAID hardware que estaba dando muy mal rendimiento de escritura, unida a un programa que realizaba del orden de 15 pequeñas escrituras aleatorias por segundo.

[/spanish]

[english]

A couple of months ago, we had an interesting issue at a customer: an application wasn’t performing well, but the system had more than 20% CPU idle and wasn’t swapping memory, so it wasn’t a lack of resources. After a deeper look into vmstat, we saw a constant 30% of CPU in I/O state. We had some kind of I/O bottleneck.

To discover the root of the issue we used two programs:

  • iostat (comes with the sysstat package): similar to vmstat or ifstat, but shows I/O operations per device and partition, updating its output every X seconds.
  • iotop: like the classic top, sorting the processes according to their I/O rate.

By using these two utilities it’s quite easy to discover which process is creating the I/O bottleneck, and on which particular device.

In our case, the problem was a RAID controller that was giving a terrible writing performance, coupled with a process that was doing around 15 small, random access writes per second.

[/english]