Aquí tenemos una captura de un servidor que se ha vuelto loco, ¡con un load average que llega a 136! (demasiado para un servidor con 2c/4t de CPU).
El reto consiste en analizar esa captura de pantalla y descubrir qué está haciendo el servidor para haber llegado a tal extremo.
Contexto
Quiero dar de baja este servidor porque necesito ahorrar dinero. Venía con un disco de 2 TB (si, un solo disco, sin RAID ni nada) que usaba para los backups de mis backups.
Pistas e indicaciones
- El load average de 1m/5m/15m debería darte una idea del tiempo que el servidor lleva trabajando así.
- Los Intel Atom CPU D525 tienen 2 cores y 4 threads, pero aún así, el rendimiento es terrible comparado a otros CPUs de Intel.
- Uno de los comandos que se ven ejecutándose es vital para entender el problema, pero estrictamente no está generando carga al CPU.
- Hace unas semanas en el FLISoL dieron una charla de seguridad informática básica muy buena: es sorprendente cómo la gente da por ciertas muchas cosas.
- La carga del sistema es alta, pero htop dice que los 4 threads de CPU están con poco trabajo.
Solución
Estoy sobreescribiendo mi disco duro con ceros, con el comando:
~# pv < /dev/zero > /dev/sda.
El comando pv me da la opción de ver cuánto del disco se ha sobreescrito con ceros y cuánto le falta para completar.
El proveedor del servidor me ha configurado el disco con ext4 (sistema de archivos que no da la opción de cifrado nativo), no configuré LUKS/dm-crypt y sé que un futuro arrendatario del servidor podría ejecutar utilidades como testdisk o photorec para recuperar contenido que yo hubiera creído ya eliminado.
El formateo a bajo nivel (llenar de ceros el disco en este caso) es una forma bruta de proteger datos, pero funciona, y los archivos son suficientemente irrecuperables para mi gusto (otras personas recomiendan múltiples pasos para contenido sensible).
En la orden ~# pv < /dev/zero > /dev/sda el proceso que escribe a /dev/sda depende directamente de la velocidad del disco duro (lento): como no puede igualar los ~1.2GB/s de /dev/zero, el caché de escritura en RAM se llena y se genera mucho I/O Wait (pausas del CPU esperando a que los datos terminen de escribirse en el disco). Además, formatear 2TB a 120MB/s da el tiempo suficiente para disparar el Load Average y llegar a cantidades absurdas.
Como bonus: htop no muestra el IOWait por defecto. Se puede activar manualmente yendo a sus opciones, o se puede usar top, que sí muestra al menos un porcentaje.