Performance analysis: A study case (bottleneck)

Como una manera de seguir ilustrando el post anterior "Performance analysis: Understanding the vmstat comand output", vamos a realizar un rápido análisis de un bottleneck producido en un equipo debido a la baja lentitud de la controladora de disco. Si bien en este caso el equipo no es más que una laptop, ejemplifica bien lo que es el estudio de performance que puede aplicarse a una gran variedad de equipos. Como en esta serie de post, solo hemos tratado con vmstat(1), utilizaremos tal herramienta para realizar el análisis.

Síntomas
El equipo, en momentos en los que se sometía a alta carga de trabajo de I/O se volvía extremadamente lento, dejando de responder por momentos, no habiendo otra solución que apagarlo, o esperar un buen rato. Si bien es entendible que el mismo se "quede" sin memoria y swapee, esto no se hacía de una manera tan agresiva, por lo cual se analizara la existencia de otro problema.

Descripción del equipo
El equipo es una laptop HP 420, con una CPU Pentium(R) Dual-Core CPU T4500 @ 2.30GHz, en cuanto a su memoría RAM se encuentra conectado un módulo DDR2 de 2 Gb. además cuenta con un disco rígido Western Digital WDC WD5000BPVT-00HXZT3 utilizando la interfaz SATAII. El sistema operativo que corre en el mismo es Linux (Fedora 16), x86_64, utilizando el kernel 3.3.1-5.fc16.x86_64. Sin entrar en más detalles vemos que dice lspci(1), sobre los dispositivos conectados al mismo:

HP-UX: Working with SAN LUN's and LVM

Las redes de storage se integran cada día más como una de las tecnologías que mas fuertemente se utilizan en los datacenters. HP-UX si bien es un OS horrible (a gusto personal), sigue teniendo gran repercusión en entornos enterprise. Muchos de estos equipos trabajan con LUN's exportadas desde un storage, como puede ser un HP EVA y más de una vez se me ha hecho necesario trabajar con ellas. En este texto, voy a comentarles como reescanear las LUN's exportadas (partiendo desde el principio que el equipo tiene una HBA), y como crear Physical Volumes, Volumen Groups y Logical Volumes con estas en HP-UX 11.31.

Linux: Enabling LVM devices from live CD.

Hoy en mi trabajo tuve que resizear un volumen group donde se encontraba como LV el root filesystem (/) de un equipo con CentOS 5.4. Esta tarea no puede ser realizada en caliente, ya que consistía en reducir de 1.5 Tb. a 300 Gb. el volumen lógico del root filesystem (LVRoot) para después reducir el Volumen Group (VolGroup00).

Uno de los problemas con que es común encontrarse es que toda la metadata de LVM esta disponible, por ejemplo utilizando pvdisplay, vgdisplay y lvdisplay; Pero en /dev no tenemos las entradas correspondientes al device mapper creadas (/dev/mapper/VolGroup00 y /dev/VolGroup00).

PoC: Playing with the ZFS compression

Como muchos sabrán, ZFS o ZettaByte filesystem es un sistema de 128 bits archivos diseñado por los ingenieros de Sun Microsystems para ser realmente grande, Jeff Bonwick, el arquitecto jefe de Sun para ZFS, dijo "Llenar un sistema de archivos de 128 bits excedería los límites cuánticos de almacenamiento de la Tierra. No puedes rellenarlo sin hervir los océanos". Una de las ventajas prácticas de ZFS es que integra el volume manager y el filesystem en un solo toolkit.

En este post, trataré de hacer una prueba de conceptos sobre uno de los features más interesantes que tiene ZFS, que es la compresión. Actualmente vivimos en una época en que el storage es un recurso barato, y el sentido de usar esta es mejorar de manera considerable el I/O del dataset, el dato al estar compreso ocupa menos, por lo cual se tienen que leer y escribir datos mas pequeños en el disco lo cual reduce la taza de I/O pero aumenta gradualmente la carga de las CPU's del equipo.

Para este ejemplo sobre FreeBSD 8.2 64 bits vamos a crear filedisks, iniciando un pool de discos con mdadm.
Vamos manos a la obra:

Linux: Recovering a corrupt superblock

Una de las estructuras más básicas del filesystem son los bloques. Estos pueden ser utilizados para dos propósitos: El primero de ellos guardar datos, el segundo almacenar metadata que referencien a dichos datos.

En otras palabras, la metadata, describe la estructura del filesystem como así también sus atributos.
Existe un bloque muy importante en los filesystem denominado superblock, este bloque contiene toda la información referida a dicho sistema de archivos, y es en quien se fija el sistema a la hora de montarlo. Por ejemplo el contendrá la cantidad de inodos, los grupos de bloques, el tipo del filesystem, el estado, el tamaño, etc. Su ubicación varía dependiendo del tamaño de bloque usado, por default este tamaño es de 1024 bytes, pero esto varía entre 2048, o 4096.