zpool iostat es uno de esos comandos que no abro todos los días, pero que me salva cuando una VM empieza a arrastrarse y nadie quiere admitir que el problema puede estar en el storage.
La web de Proxmox te da gráficas. Algunas son útiles. Otras son demasiado bonitas para el estado mental que tengo cuando algo va lento. Si una copia de seguridad tarda el doble, si una VM se queda medio congelada al actualizar paquetes, si un contenedor responde tarde sin tocar CPU ni RAM, yo quiero ver qué está haciendo ZFS justo en ese momento.
Ahí entra zpool iostat.
No mira el disco desde la perspectiva de Linux como iostat. Mira el pool ZFS. Eso cambia bastante la lectura. En un pool con mirrors, discos NVMe, datasets, zvols y VMs moviendo datos a la vez, me interesa ver cómo reparte ZFS las operaciones y el ancho de banda. No necesito una tesis. Necesito saber si el pool está respirando o si está tragando agua.
El comando base es este.
| |
Pero casi nunca lo uso así. En Proxmox suelo ir directo al pool y con detalle por vdev.
| |
Ese 2 5 significa que actualiza cada dos segundos y muestra cinco lecturas. Es suficiente para ver si hay un pico puntual o una carga sostenida. Si lo dejo sin límite, acabo mirando números como si estuviera esperando que el servidor confiese. Y no, mejor no convertir la terminal en una bola de cristal.
la captura de este post#
La captura está hecha con una salida saneada de un nodo Proxmox real. He quitado nombres concretos y he dejado un pool genérico. Los números son verosímiles para un pool ZFS con mirrors NVMe en uso moderado. No hay IPs, dominios internos ni rutas privadas.
Esta es la salida saneada que usé para generar la captura:
| |
La gracia no está en memorizar cada columna. La gracia está en leer la historia sin ponerse nervioso.
por qué no empiezo por la web de Proxmox#
La interfaz de Proxmox me sirve para muchas cosas. Para mover una VM, revisar tareas, ver storage activo o comprobar una gráfica general, perfecta. Pero cuando hablo de I/O real, prefiero terminal.
La web agrega datos. ZFS tiene sus propias capas. Una VM puede estar quieta desde el punto de vista de CPU y aun así tener un disco haciendo pequeñas escrituras constantes. Un backup puede parecer normal hasta que ves que está machacando el pool con operaciones pequeñas. Un contenedor puede parecer sospechoso porque responde lento, pero el problema puede ser otro servicio escribiendo logs como si le pagasen por línea.
zpool iostat me baja a la capa donde ZFS ve las cosas. No sustituye a iostat, no sustituye a arcstat, no sustituye a los logs. Pero me da una lectura rápida del pool.
Lo uso sobre todo en cuatro momentos.
- Antes de reiniciar una VM que parece lenta.
- Durante backups pesados.
- Mientras muevo discos entre storages.
- Cuando el panel dice que todo está bien pero el cuerpo no se lo cree.
Ese último punto no es científico, pero cualquiera que tenga un homelab con algo de vida sabe de qué hablo.
capacity: alloc y free no son el foco, pero los miro#
La primera parte de la salida muestra capacidad.
| |
No es el motivo principal por el que abro zpool iostat, pero lo miro igualmente. Si el pool está al 90 por ciento, cualquier lectura de rendimiento tiene otro sabor. ZFS no lleva bien vivir apretado. Puede funcionar, claro, pero no es donde quiero tener mis VMs importantes.
Aquí el pool va sobrado. 612 GB usados y 4.30 TB libres. Si una VM va lenta con este pool, no parece un caso de espacio agotado. Eso no descarta fragmentación, latencia, discos raros o carga puntual, pero me quita una sospecha grande de encima.
Cuando el pool está muy lleno, mi lectura cambia. Ya no miro solo operaciones y bandwidth. Miro también snapshots antiguos, discos huérfanos, backups locales que no deberían estar ahí y datasets con crecimiento raro.
ZFS tiene una forma muy elegante de dejarte cavar tu propia tumba si lo tratas como un disco USB gigante. En Proxmox conviene darle aire.
operations: aquí se ve si hay muchas pequeñas tareas#
La columna que más miro es operations.
| |
Esto no son megas por segundo. Son operaciones. Muchas operaciones pequeñas pueden molestar más que una escritura grande y limpia. Una VM haciendo actualizaciones, una base de datos escribiendo en disco, un servicio con logs agresivos o un backup con muchos ficheros pequeños pueden subir estas cifras sin que el ancho de banda parezca espectacular.
En la captura hay 18 lecturas y 92 escrituras. No me asusta. Es actividad. Si viera miles de operaciones sostenidas y al mismo tiempo quejas de latencia, entonces empezaría a tirar del hilo.
Aquí hay una trampa típica. Mucha gente mira solo MB/s. Si no ve 500 MB/s, piensa que el storage no está ocupado. Pero una carga de I/O pequeña y constante puede sentirse peor que una transferencia grande. Especialmente si las escrituras son síncronas o si hay muchas VMs compartiendo el mismo pool.
Por eso miro operations antes de sacar conclusiones. Me dice el tipo de ruido que tiene el pool.
bandwidth: útil, pero no cuenta toda la historia#
La otra parte importante es bandwidth.
| |
Aquí sí hablamos de ancho de banda. En la captura el pool está escribiendo unos 14.8 MB/s y leyendo 2.1 MB/s. Para un pool NVMe eso es poca cosa. Si una VM va lenta con esos números, probablemente el problema no sea que el pool esté saturado en bruto.
Pero no cierro el caso solo por eso. Puede haber latencia, escrituras síncronas, un disco con problemas, un vdev descompensado o una capa superior haciendo tonterías. El ancho de banda me dice cuánto volumen se mueve. No me dice si cada operación está tardando demasiado.
Cuando veo bandwidth alto durante un backup, no me molesta. De hecho, me tranquiliza. Significa que el pool está trabajando y el backup está avanzando. Lo que me preocupa es ver bandwidth bajo, operaciones altas y usuarios quejándose. Eso huele a I/O pequeño, latencia o cuello de botella en otra parte.
Y si veo escritura constante cuando no debería pasar nada, entonces miro qué VM se ha emocionado.
el valor de -v: mirar los vdevs#
Sin -v, zpool iostat te da el pool agregado. Con -v, baja a vdevs y discos.
| |
Esto me gusta porque veo si los mirrors están trabajando de forma parecida. En la captura lo están. Mirror 0 y mirror 1 tienen carga muy similar. Eso es buena señal.
Si un vdev estuviera haciendo mucho más trabajo que otro, me pararía. Puede ser normal según cómo esté distribuido el pool, pero también puede indicar que el layout no está equilibrado o que ciertas cargas viven en zonas concretas. ZFS no reequilibra datos antiguos por arte de magia cuando añades vdevs. Esto conviene recordarlo antes de ampliar un pool y esperar milagros.
En mirrors, también miro que los discos dentro del mirror no tengan una diferencia absurda.
| |
No busco igualdad perfecta. Busco que no haya un disco claramente raro. Si uno lee cero, otro lo hace todo y además zpool status empieza a contar errores, ya no estoy en modo observación. Estoy en modo mantenimiento.
cómo lo uso cuando una VM va lenta#
Mi rutina es bastante simple.
Primero miro el estado básico de la VM.
| |
Luego miro si hay tareas recientes.
| |
Después abro zpool iostat.
| |
Si veo I/O alto, no culpo a la VM todavía. Miro si hay backups, migraciones, scrubs, snapshots o tareas de Proxmox en curso. Muchas veces la VM solo es la que grita más alto, no la culpable.
Si veo I/O bajo, entonces miro dentro de la VM. CPU steal, memoria, swap, red, DNS, base de datos, procesos bloqueados. El storage puede estar perfectamente tranquilo mientras una aplicación se pega un tiro en el pie.
Esto parece obvio escrito aquí. A las dos de la mañana, con un servicio lento y sueño atrasado, no lo es tanto. Tener una rutina corta evita hacer el bruto.
durante backups cambia la lectura#
Los backups ensucian cualquier diagnóstico. Si Proxmox Backup Server está leyendo discos grandes, comprimiendo, deduplicando o verificando chunks, el pool va a moverse. Eso no es malo.
Lo que miro durante un backup no es si hay actividad. Claro que la hay. Miro si la actividad tiene sentido.
Si el backup de una VM grande está escribiendo o leyendo a buen ritmo, bien. Si el backup se queda clavado y zpool iostat muestra actividad mínima, el problema puede estar en red, destino, PBS, bloqueo de la VM o snapshot. Si el pool va a tope y el backup avanza lento, entonces miro latencia y tipo de carga.
También comparo con pvesm status.
| |
No porque me dé I/O fino, sino porque quiero confirmar que los storages están activos y que no estoy leyendo un problema de montaje como si fuera rendimiento.
no confundas zpool iostat con benchmark#
Esto no es un benchmark. No uses zpool iostat para presumir de NVMe en un foro. Para eso ya hay suficiente folklore.
zpool iostat observa lo que pasa. Si no hay carga, no te va a enseñar el máximo rendimiento del pool. Si hay una carga rara, te va a enseñar esa carga rara. Para medir rendimiento de forma controlada necesitas herramientas y metodología. Para diagnosticar un homelab un martes cualquiera, muchas veces basta con mirar bien.
Yo lo uso como monitor de pulso. Si el pulso está tranquilo, busco en otra parte. Si el pulso está disparado, intento saber quién está corriendo.
errores que he cometido con este comando#
El primero fue mirar una sola muestra. Mala idea. La primera línea puede ser una media desde que arrancó el sistema, según cómo invoques el comando y versión. Lo útil es usar intervalo.
| |
El segundo fue mirar solo el pool agregado. Si tienes varios vdevs, usa -v. Si no, pierdes justo la parte interesante.
El tercero fue ignorar el contexto. Ver 100 MB/s de escritura no significa problema si estás haciendo un backup. Ver 5 MB/s no significa tranquilidad si son escrituras pequeñas y síncronas que machacan latencia.
El cuarto fue olvidar que ZFS no es la única capa. Una VM lenta puede tener el storage bien y estar sufriendo por DNS, swap, una base de datos mal configurada o una aplicación haciendo una consulta absurda.
No hay comando que arregle eso. Por desgracia. Si existiera, lo tendría en alias y dormiría más.
mi lectura rápida#
Cuando abro zpool iostat, sigo este orden.
- Miro si el pool tiene actividad real.
- Comparo lecturas contra escrituras.
- Reviso operaciones, no solo MB/s.
- Bajo con
-vpara ver vdevs. - Cruzo con tareas de Proxmox.
- Decido si sigo por storage o subo a la VM.
No necesito más para una primera decisión.
La clave está en no convertir cada lentitud en un drama de discos. A veces ZFS está tranquilo y el problema vive arriba. Otras veces el pool está moviendo más de lo que pensabas porque un backup, una migración o una VM con logs infinitos está haciendo ruido.
zpool iostat no te da una respuesta mágica. Te da una conversación bastante directa con el pool. Y en un homelab con Proxmox, eso vale mucho más que mirar una gráfica bonita esperando que parpadee en rojo.