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









  • english
  • spanish

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.