Proxmox más lento tras una actualización: las primeras comprobaciones que suelen revelar la causa

Guía de diagnóstico rápido (primero/segundo/tercero)

Si tienes una hora para detener la hemorragia, haz esto. No abras veinte madrigueras. Elige el cuello de botella de alto nivel primero y luego profundiza.

Primero: identifica qué recurso está saturado ahora mismo

• CPU del host: comprueba la carga frente al uso de CPU y el tiempo de %steal. Carga alta con uso de CPU bajo grita “espera por I/O” o contención de locks.
• I/O del host: comprueba latencia de disco y profundidad de cola. Un poco de latencia está bien; latencias sostenidas de decenas de milisegundos en I/O aleatorio son un crimen de rendimiento.
• Red: comprueba pérdidas, errores y desajustes en MTU/offloads. La pérdida silenciosa de paquetes es “funciona en desarrollo” para producción.

Segundo: decide si el problema es del host entero o específico de una VM

• Si todas las VMs se ralentizaron de forma similar tras la actualización, sospecha del kernel del host, backend de almacenamiento, driver/offload de NIC o servicios de clúster.
• Si solo un subconjunto se ralentizó, sospecha de ajustes de hardware específicos de la VM (virtio/scsi controller, modo cache), drivers del invitado o límites por VM.

Tercero: compara “antes vs después” con la línea base más simple

• Ejecuta una micro-prueba de I/O desde el host (con cuidado) para ver si el subsistema de almacenamiento ha empeorado.
• Realiza una comprobación de CPU e I/O dentro de una VM única para confirmar que el hipervisor no es el culpable.
• Comprueba si la actualización cambió kernel, versiones de ZFS/Ceph, el planificador de I/O o los valores por defecto de QEMU.

Regla empírica: si no puedes señalar a uno de CPU, I/O o red como “dominante” en los primeros 15 minutos, no estás mirando los contadores correctos.

Qué cambian las actualizaciones (y por qué importa)

Las actualizaciones de Proxmox son engañosamente “un clic”. Bajo ese clic: un nuevo kernel, nuevo QEMU, pilas de almacenamiento actualizadas (ZFS, clientes/daemons de Ceph si los usas), nuevos drivers de NIC, nuevos valores por defecto y, ocasionalmente, nuevos comportamientos en cgroups, planificación y administración de energía.

Las regresiones de rendimiento tras actualizaciones típicamente encajan en estos apartados:

• Cambios en kernel/driver: distinto planificador de I/O por defecto, comportamiento de offload de NIC, manejo de IRQ, gobernador de frecuencia de CPU o una regresión del driver.
• Cambios en la pila de almacenamiento: versiones de ZFS que afectan el comportamiento del ARC o el manejo de escrituras sync; versiones de Ceph que cambian la recuperación/backfill.
• Deriva en la configuración de hardware de la VM: tipos de controladora, modos de caché, iothreads, ballooning o cambios en el modelo de CPU.
• Servicios de clúster: sensibilidad de corosync a latencias, problemas de sincronización horaria o comportamiento “útil” del watchdog.
• Trabajo en segundo plano nuevo: scrubs/resilvers, reequilibrado de Ceph, escaneos SMART, sondeo pvestatd, tormentas de logs.

Las actualizaciones también exponen pecados existentes. Tu plataforma puede haber sobrevivido gracias a cachés afortunados, subutilización tranquila o una peculiaridad del driver que resultó beneficiosa. Las actualizaciones quitan esa suerte.

Una cita para colgar en la pared:

“La esperanza no es una estrategia.” — James Cameron

Aplica también a las actualizaciones: trátalas como gestión de cambios, no como una corazonada.

Datos interesantes y contexto histórico

1. KVM llegó al kernel de Linux en 2007, y ganó en gran parte porque era “simplemente” el kernel de Linux haciendo virtualización, no un hipervisor separado.
2. Virtio fue diseñado para evitar emular hardware heredado lento. Cuando faltan drivers virtio o están desajustados, puedes ver diferencias de 10× en rendimiento de almacenamiento y NIC.
3. ZFS llegó a Linux vía un puerto (OpenZFS), y es famoso por la integridad de datos—pero también por ser sensible a RAM, patrones de escritura sync y datasets mal sintonizados.
4. El rendimiento de Ceph puede parecer “bien” mientras está degradado porque seguirá sirviendo I/O mientras hace recuperación y backfill en segundo plano.
5. Linux fue migrando muchos sistemas a cgroup v2 por defecto; cambios en planificación y contabilidad pueden afectar sutilmente hosts Proxmox con muchas containers.
6. Los NVMe modernos son rápidos pero no consistentemente mágicos: firmware, estados de energía y limitación térmica pueden crear patrones de latencia “sierra” tras reinicios.
7. Los planificadores de I/O cambiaron de filosofía: para dispositivos rápidos, “none” suele ganar; para discos más lentos, los planificadores que fusionan requests pueden reducir picos de latencia.
8. El escalado de frecuencia de CPU es una variable de rendimiento, no una casilla verde. Un distinto valor por defecto de kernel puede moverte de predecible a lento bajo carga explosiva.
9. Corosync depende de entrega oportuna en la red. Un pequeño aumento de latencia/jitter puede provocar flaps de membresía, que se ven como “lentitud aleatoria” en otras partes.

Comienza desde primeros principios: define “más lento” correctamente

“Más lento” es una queja. Necesitas un síntoma que puedas medir.

Elige una o dos cargas representativas y define la regresión en números:

• Base de datos: latencia de commit percentil 95, tasa de aciertos de buffer cache, tiempo de fsync.
• Web/API: percentiles de latencia de petición, tasa de errores, saturación de CPU, cola de ejecución.
• Servidor de archivos: rendimiento SMB/NFS, latencia de operaciones de metadatos, creación de archivos pequeños.
• Copias de seguridad: MB/s y tiempo transcurrido, además de latencia de escritura de almacenamiento durante la ventana de backups.

Luego determina dónde ocurre la espera. La mayoría de las veces es uno de estos:

• Espera por I/O en el host: picos de latencia en almacenamiento, colas que se forman, VMs bloqueadas.
• Retraso en la planificación de CPU: demasiadas tareas ejecutables, errores de pinning, tormentas de IRQ.
• Pérdida/jitter de red: retransmisiones y timeouts, corosync irritado, replicación de almacenamiento lenta.
• Desajuste de drivers a nivel de invitado: drivers virtio obsoletos, modelo de controladora incorrecto, modos de caché extraños.

Broma #1: Las regresiones de rendimiento son como “una reunión más”: nadie las agenda, pero todos asisten.

Tareas prácticas: comandos, salidas y decisiones

Estas son las primeras comprobaciones que yo ejecuto en un host Proxmox tras una actualización cuando alguien dice “está más lento”. Cada tarea incluye: comando, qué aspecto tiene bueno/malo y qué decisión tomar.

Task 1: Confirmar qué cambió realmente (kernel, pve, qemu)

cr0x@server:~$ pveversion -v
pve-manager/8.2.2/bb2d... (running kernel: 6.8.12-3-pve)
proxmox-ve: 8.2-1 (running kernel: 6.8.12-3-pve)
qemu-server/8.2.4/...
libpve-storage-perl/8.2.2/...

Significado: Ahora sabes las versiones de kernel y de la pila en juego. “Se volvió más lento” a menudo coincide con “cambió el kernel” o “cambió QEMU”.

Decisión: Si la regresión empezó justo después de esto, prioriza las comprobaciones de kernel/driver/pila de almacenamiento antes de perseguir afinados específicos de VM.

Task 2: Comprobar si el host está limitado por CPU, I/O o está confundido

cr0x@server:~$ uptime
 14:02:11 up 12 days,  3:45,  3 users,  load average: 18.21, 16.77, 15.90

Significado: El load average cuenta tareas ejecutables y tareas en sleep ininterrumpible (a menudo I/O). Carga alta no significa automáticamente CPU alta.

Decisión: Combina esto con uso por CPU y iowait a continuación. Si la carga es alta pero el uso de CPU es moderado, sospecha de latencia de almacenamiento o contención de locks del kernel.

Task 3: Buscar iowait y tiempo de steal en el host

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.12-3-pve (server)  12/26/2025  _x86_64_  (32 CPU)

Average:     CPU   %usr   %nice    %sys %iowait   %irq  %soft  %steal  %idle
Average:     all   12.40    0.00    4.10   18.70   0.00   0.80    0.00  64.00
Average:       0   10.00    0.00    3.00   22.00   0.00   0.50    0.00  64.50

Significado: Un %iowait sostenido en la decena (o superior) significa que la CPU espera por almacenamiento. %steal suele ser 0 en bare metal, pero en virtualización anidada importa.

Decisión: Si iowait es alta, deja de “afinar CPU”. Ve directamente a latencia de almacenamiento y profundidad de cola.

Task 4: Identificar procesos top y si están bloqueados por IO

cr0x@server:~$ top -b -n 1 | head -25
top - 14:02:33 up 12 days,  3:45,  3 users,  load average: 18.21, 16.77, 15.90
Tasks: 812 total,   5 running, 807 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.3 us,  4.1 sy,  0.0 ni, 64.0 id, 18.7 wa,  0.0 hi,  0.9 si,  0.0 st
MiB Mem : 256000.0 total,  84000.0 free,  42000.0 used, 130000.0 buff/cache
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
8421 root      20   0 11.8g   2.1g  10500 S  180.0  0.8  90:12.22 kvm
9211 root      20   0 10.2g   1.9g   9700 D   40.0  0.7  15:44.01 kvm

Significado: El estado D significa sleep ininterrumpible—a menudo bloqueado por I/O. Ver hilos KVM en estado D es un indicador clásico de “el almacenamiento está atascando las VMs”.

Decisión: Pasa a comprobaciones de latencia a nivel de dispositivo (iostat, nvme smart-log, salud ZFS/Ceph) antes de tocar la configuración de las VMs.

Task 5: Medir latencia de disco y colas por dispositivo

cr0x@server:~$ iostat -x 1 5
Linux 6.8.12-3-pve (server)  12/26/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.35    0.00    4.12   18.69    0.00   64.84

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         120.0  980.0   4200.0 128000.0    240.0     9.80    9.60     2.10    10.50   0.35  38.0
sda               2.0   80.0     40.0   1800.0     46.0     3.20   45.00     8.00    46.00   1.20  95.0

Significado: Observa await y avgqu-sz. Un dispositivo lento con alta utilización y await elevada (como sda arriba) puede arrastrar todo el camino de almacenamiento si forma parte del pool/array o se usa para logs.

Decisión: Si un dispositivo está al 100% de %util con await grande, identifica para qué se usa (¿vdev especial de ZFS? ¿disco de arranque? ¿Ceph WAL/DB?) y corrige esa ruta.

Task 6: Confirmar salud del pool ZFS y si está haciendo trabajo en segundo plano

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
 scan: resilver in progress since Thu Dec 26 12:11:09 2025
        1.22T scanned at 1.80G/s, 220G issued at 320M/s, 3.45T total
        220G resilvered, 6.2% done, 02:45:12 to go
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     0

Significado: Un resilver o scrub puede golpear el I/O. Tras una actualización/reinicio, estos trabajos pueden iniciar o reanudarse.

Decisión: Si estás en una emergencia de rendimiento, considera programar scrubs/resilvers con criterio (no “nunca”), y reducir cargas competitivas durante ventanas de recuperación.

Task 7: Comprobar propiedades de dataset ZFS que afectan latencia (sync, compression, recordsize)

cr0x@server:~$ zfs get -o name,property,value -s local,received sync,compression,recordsize,logbias,primarycache rpool/data
NAME        PROPERTY     VALUE
rpool/data  sync         standard
rpool/data  compression  zstd
rpool/data  recordsize   128K
rpool/data  logbias      latency
rpool/data  primarycache all

Significado: Las actualizaciones no suelen cambiar estas propiedades por sí solas, pero migraciones y “afinados útiles” a veces sí. sync y logbias son palancas de latencia para cargas con muchas escrituras sincrónicas.

Decisión: Si ves sync=always inesperadamente, espera menor rendimiento en bases de datos. Arregla la causa raíz (exports NFS? dataset heredado?) en lugar de desactivar sync a ciegas.

Task 8: Observar presión del ARC de ZFS (memoria vs comportamiento de caché)

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  size     c
14:03:51   812   120     14    28    3    70    8    22    3  96.1G  108G
14:03:52   790   140     17    31    4    81   10    28    4  95.9G  108G
14:03:53   840   160     19    35    4    91   11    34    4  95.8G  108G

Significado: Un aumento del porcentaje de misses y reducción del ARC puede empujar más lecturas al disco. Tras actualizaciones, los patrones de presión de memoria pueden cambiar (containers, servicios, uso de memoria del kernel).

Decisión: Si el ARC está constantemente reducido, valida la asignación de RAM del host, el ballooning y si nuevos servicios (p. ej. daemons de Ceph) compiten por memoria.

Task 9: Confirmar salud de Ceph y si está recuperando/rebalanceando

cr0x@server:~$ ceph -s
  cluster:
    id:     9e2a...c6
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 24/1024 objects degraded
            Reduced data availability: 8 pgs inactive
  services:
    mon: 3 daemons, quorum pve1,pve2,pve3
    mgr: pve1(active), standbys: pve2
    osd: 11 osds: 10 up, 11 in
  data:
    pools:   4 pools, 256 pgs
    objects: 1.2M objects, 4.1 TiB
    usage:   12 TiB used, 24 TiB / 36 TiB avail
    pgs:     8 inactive, 24 degraded
  io:
    client:   220 MiB/s rd, 45 MiB/s wr, 1.8k op/s rd, 0.6k op/s wr

Significado: Un estado “WARN” con PGs degradados y recuperación significa que el I/O cliente compite con el I/O de recuperación. El rendimiento será inconsistente.

Decisión: Arregla primero el problema de salud. Afinar un Ceph enfermo es como reorganizar las sillas durante turbulencias.

Task 10: Comprobar si recovery/backfill está consumiendo el clúster

cr0x@server:~$ ceph tell 'osd.*' perf dump | head
{
    "filestore": {
        "journal_queue_max_ops": 500,
        "op_queue_max_ops": 1000
    },
    "throttle-msgr_dispatch_throttler": {
        "val": 0
    }
}

Significado: Esta es una mirada burda. En la práctica mirarás tasas de recovery, backfill y contadores de perf de OSD para ver si el clúster está ocupado “arreglándose”.

Decisión: Si la recuperación es intensa y el negocio necesita rendimiento ahora, ajusta temporalmente parámetros de recovery (con cuidado) y programa reparaciones. Pero no dejes esos límites permanentemente por miedo.

Task 11: Verificar errores de NIC, drops y estado de enlace

cr0x@server:~$ ip -s link show dev bond0
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    91234567890  81234567  0       124      0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    78123456789  73456789  0       0        0       0

Significado: Drops en RX tras una actualización pueden deberse a offloads, tamaño de buffer de ring, regresión del driver o desajuste de MTU causando fragmentación/agujeros negros.

Decisión: Si los drops aumentan de forma sostenida, trátalo como un incidente de red. Revisa offloads, MTU end-to-end, contadores del switch y driver/firmware.

Task 12: Comprobar que bridge y VLAN coinciden con lo que crees que desplegaste

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
        bond-slaves eno1 eno2
        bond-miimon 100
        bond-mode 802.3ad
        mtu 9000

auto vmbr0
iface vmbr0 inet static
        address 10.10.0.11/24
        gateway 10.10.0.1
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        mtu 9000

Significado: Tras la actualización, a veces un cambio de nombre de interfaz, un módulo faltante o una configuración mal aplicada crea una ruta “casi funcional” pero degradada (p. ej., bond degradado a un enlace, MTU inconsistente).

Decisión: Si la configuración no coincide con tu diseño, corrígela primero. No hagas benchmarks en medio del caos.

Task 13: Comprobar latencia del anillo corosync (la “lentitud” del clúster puede ser comunicaciones de clúster)

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
        id      = 10.10.0.11
        status  = ring 0 active with no faults
RING ID 1
        id      = 10.20.0.11
        status  = ring 1 active with no faults

Significado: Esto muestra el estado del anillo, no el rendimiento. Si ves fallos o flaps de anillo, tu “lentitud” puede ser churn del estado del clúster.

Decisión: Si los anillos son inestables, detente y arregla la red/sincronización horaria. HA, migraciones y coordinación de almacenamiento empeorarán.

Task 14: Buscar pistas en logs del kernel (resets de driver, timeouts NVMe, soft lockups)

cr0x@server:~$ journalctl -k -p warning --since "2 hours ago" | tail -20
Dec 26 12:44:10 server kernel: nvme nvme0: I/O 123 QID 6 timeout, reset controller
Dec 26 12:44:11 server kernel: nvme nvme0: controller reset succeeded
Dec 26 12:58:22 server kernel: ixgbe 0000:3b:00.0: Detected Tx Unit Hang

Significado: Timeouts y resets son asesinos de rendimiento que a menudo se disfrazan de “lentitud aleatoria”. Tras una actualización, cambios en drivers pueden exponer hardware marginal o bugs de firmware.

Decisión: Si ves resets/hangs, deja de culpar a Proxmox y empieza a aislar combinaciones firmware/driver, cableado y salud del hardware.

Task 15: Validar gobernador de frecuencia de CPU y ajustes de energía

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Significado: “powersave” puede estar bien en algunas plataformas, terrible en otras. Tras actualizaciones, los valores por defecto pueden cambiar, o microcode puede alterar el comportamiento de boost.

Decisión: Si cargas sensibles a la latencia empeoraron y estás en powersave, prueba cambiar a performance (con control de cambios) y mide.

Task 16: Comprobar la configuración de la VM para regresiones en controladora de disco y modo de caché

cr0x@server:~$ qm config 104 | egrep 'scsi|virtio|cache|iothread|cpu|balloon'
balloon: 4096
cpu: x86-64-v2-AES
scsi0: rpool/data/vm-104-disk-0,cache=writeback,iothread=1,discard=on,size=200G
scsihw: virtio-scsi-single

Significado: Los modos de caché y tipos de controladora importan. cache=writeback puede ser rápido y peligroso sin garantías de almacenamiento duradero; otros modos pueden ser más seguros pero más lentos. virtio-scsi-single con iothread puede ayudar la paralelización.

Decisión: Si solo ciertas VMs empeoraron, compara sus configs. Un cambio en el modelo de CPU o la falta de iothread puede aparecer como “todo se volvió más lento” para esa carga.

Regresiones de almacenamiento: ZFS, Ceph y “¿dónde se fueron mis IOPS?”

La mayoría de incidentes “Proxmox lento” tras una actualización son en realidad incidentes de latencia de almacenamiento. El hipervisor recibe la culpa porque es la capa común. El almacenamiento es donde cambios pequeños se convierten en dolor visible.

ZFS en Proxmox: patrones clásicos de regresión

ZFS es fantástico cuando respetas sus necesidades: RAM, una disposición sensata de vdevs y una historia clara para escrituras sync. También es implacable cuando lo tratas como ext4 con buenas intenciones.

1) Las escrituras sync se volvieron caras

Las bases de datos y los discos de VM hacen escrituras sync. Si tu almacenamiento subyacente no puede confirmarlas rápido, todo se atasca. Disparadores comunes tras una actualización:

• Un dispositivo usado como SLOG ahora es lento, está fallando o falta.
• Una actualización de kernel cambió el comportamiento NVMe o el encolado.
• La carga cambió ligeramente y cruzó un umbral donde los picos de latencia se volvieron constantes.

Comprueba si tienes un SLOG y si está sano:

cr0x@server:~$ zpool status
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     0
        logs
          nvme2n1   ONLINE       0     0     0

Decisión: Si existe un dispositivo de log dedicado, verifica que no sea el cuello de botella. Un SLOG lento puede convertir escrituras sync en melaza.

2) vdev special y puntos calientes de metadata

Si usas special vdevs (metadata/bloques pequeños), una regresión en ese dispositivo perjudica todo. Revisa latencias desiguales en iostat y en SMART/salud del dispositivo.

3) El comportamiento del ARC cambió por presión de memoria

Tras actualizaciones, puede que estés ejecutando más servicios (módulos mgr de Ceph, exporters, daemons extra), o que el accounting de containers cambió. El ARC se aprieta, la latencia de lectura sube y obtienes “lentitud aleatoria” que en realidad es “tormenta de misses de caché”.

4) Incompatibilidad entre recordsize de ZFS y la carga

Recordsize no es un juguete de afinado; es una decisión de diseño de datos. La mayoría de imágenes VM funcionan bien con 128K, pero algunas cargas random se benefician de bloques más pequeños. Las actualizaciones no cambian recordsize, pero cambian el entorno lo suficiente como para que finalmente notes el desajuste.

Ceph en Proxmox: salud primero, afinado después

Ceph no es “un disco”. Es un sistema distribuido que almacena bytes. Tras una actualización, los asesinos de rendimiento más comunes son:

• OSDs flappeando por problemas de red o timeouts
• Recovery/backfill consumiendo I/O y red
• MTU o offloads de NIC desajustados causando pérdida y retransmisiones
• Cambios CRUSH o reweights que disparan reequilibrado
• Cambios en el cliente del kernel (si usas RBD) que afectan latencia

Si estás lento y Ceph no está HEALTH_OK, trata la advertencia como causa raíz hasta que se demuestre lo contrario.

Haz benchmarks con cuidado, o te diagnosticarás a ti mismo

Usa fio solo cuando entiendas el radio de explosión. No ejecutes un benchmark de escritura aleatoria en un pool de producción al mediodía y lo llames “diagnóstico”. Te diagnosticarás a ti mismo hasta convertirlo en un incidente.

Dicho esto, un benchmark controlado y pequeño puede confirmar si el rendimiento del almacenamiento del host cambió fundamentalmente:

cr0x@server:~$ fio --name=latcheck --filename=/rpool/data/latcheck.bin --size=2G --direct=1 --rw=randread --bs=4k --iodepth=16 --numjobs=1 --runtime=20 --time_based=1 --group_reporting
latcheck: (groupid=0, jobs=1): err= 0: pid=18821: Thu Dec 26 14:10:12 2025
  read: IOPS=52.1k, BW=203MiB/s (213MB/s)(4062MiB/20001msec)
    slat (nsec): min=920, max=112k, avg=2450.1, stdev=2100.4
    clat (usec): min=60, max=7800, avg=286.2, stdev=120.4
    lat  (usec): min=63, max=7805, avg=289.0, stdev=121.0

Significado: Buscas la distribución de latencias: media y máximos. Unos pocos ms de máximo suelen estar bien; decenas/centenas de ms de máximo bajo carga ligera indican stalls de almacenamiento.

Decisión: Si esto es dramáticamente peor que tu baseline conocido (o peor que otros hosts), céntrate en salud del dispositivo, logs del kernel, trabajo en segundo plano ZFS/Ceph y cambios en la configuración de almacenamiento.

CPU y planificación: tiempo robado, pinning y sorpresas del kernel

Cuando el almacenamiento está bien, la planificación de CPU es la siguiente regresión más común tras una actualización. Proxmox es Linux; Linux es genial; Linux también es perfectamente capaz de programarte hacia un barranco si le das las restricciones equivocadas.

Regresión común de CPU tras actualización: escalado de frecuencia

Algunas actualizaciones cambian el driver de CPUfreq usado (intel_pstate vs acpi-cpufreq), o revierten un gobernador afinado. El síntoma es predecible: el rendimiento single-thread cae, la latencia sube y el uso global de CPU puede seguir pareciendo moderado.

Comprueba la política actual:

cr0x@server:~$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 2>/dev/null | head
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:powersave

Decisión: Si esperas rendimiento consistente, considera fijar una política explícita (y documentarla). Mide antes y después; no la cambies y declares victoria sin datos.

Tormentas de IRQ y consumo de CPU por softirq

Tras actualizaciones de drivers NIC, puedes tener diferente comportamiento de interrupciones. Síntomas:

• Alto %soft en mpstat
• Caída del throughput de red mientras sube la CPU
• Aumento de drops de paquetes

Mira las interrupciones:

cr0x@server:~$ cat /proc/interrupts | head -15
           CPU0       CPU1       CPU2       CPU3
  0:         42          0          0          0   IO-APIC   2-edge      timer
 24:   81234567   79234561   80123455   81111222   PCI-MSI  524288-edge  ixgbe
 25:       1024       1100       1008       990    PCI-MSI  524289-edge  ixgbe

Decisión: Si uno o dos CPUs son barridos por interrupciones tras la actualización, investiga la afinidad de IRQ y la configuración de colas de la NIC. No “arregles” dando más vCPUs a las VMs sin entender el problema.

Pinning de CPU: genial cuando es correcto, brutal cuando falla

El pinning puede mejorar rendimiento en cargas sensibles a latencia. También puede crear contención artificial cuando cambias topología de CPU, microcode o comportamiento del scheduler del kernel.

Revisa VMs con pinning y sus máscaras de CPU. En Proxmox esto aparece a menudo en la config de VM (cores, cpulimit, cpuunits) y en herramientas de afinado a nivel host.

Los kernels también pueden cambiar cómo CFS balancea tareas entre CPUs. Si estás pinning demasiado y tienes finalizaciones de I/O en las mismas CPUs, te estás peleando contigo mismo.

Regresiones de red: bridges, offloads, MTU y corosync

Las regresiones de red tras una actualización son sigilosas. Las pruebas de throughput pueden parecer bien, pero el tráfico sensible a latencia (replicación de almacenamiento, corosync, RPCs pequeños) sufre.

Desajuste de MTU: el clásico “funciona pero es lento”

Si usas jumbo frames (MTU 9000) en bonds/bridges, debes asegurarte de que sea consistente end-to-end: NIC, bond, bridge, puertos de switch, VLANs y endpoints pares (incluida la red de almacenamiento). Un desajuste puede llevar a fragmentación o drops según el camino y el comportamiento del bit DF.

Comprueba MTU en cada capa:

cr0x@server:~$ ip link show vmbr0 | grep mtu
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Decisión: Si algunos nodos muestran MTU 9000 y otros 1500, arregla la inconsistencia antes de culpar al almacenamiento.

Offloads y cambios de driver

Tras actualizaciones, los valores por defecto de offloads NIC pueden cambiar. A veces los offloads ayudan, otras veces introducen rarezas con bridges/VLANs o firmware de switches específicos. Si ves drops y retransmisiones, revisa offload settings y prueba cambios con cuidado.

cr0x@server:~$ ethtool -k eno1 | egrep 'tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Decisión: Si sospechas de offload-related issues, prueba a alternar un cambio a la vez y mide. No apagues todo por imitacion.

Sensibilidad de corosync

Corosync no necesita gran ancho de banda. Necesita bajo jitter y poca pérdida. Una pequeña regresión de red puede causar inestabilidad de clúster, que a su vez provoca daño secundario al rendimiento: migraciones fallan, decisiones HA hacen churn y operaciones de almacenamiento se retrasan.

Busca quejas de corosync:

cr0x@server:~$ journalctl -u corosync --since "24 hours ago" | tail -20
Dec 26 09:15:22 server corosync[1482]: [TOTEM ] Token has not been received in 2500 ms
Dec 26 09:15:22 server corosync[1482]: [TOTEM ] A processor failed, forming new configuration.

Decisión: Si ves timeouts de token, trátalo como problema de red/tiempo. Arregla eso antes de intentar afinado de rendimiento en otros lados.

Cambios en QEMU/VM que perjudican silenciosamente

A veces el host está bien y la regresión es específica: solo VMs Windows, solo una VM de base de datos, solo VMs en un almacenamiento, solo VMs creadas tras la actualización.

Drivers virtio y herramientas del invitado

Invitados Windows sin drivers virtio actualizados pueden empeorar tras cambios del hipervisor. Los invitados Linux suelen manejarlo mejor, pero kernels antiguos aún pueden tener problemas con nuevas funciones virtio.

Comprueba si el agente QEMU del invitado está flapping o malfuncionando:

cr0x@server:~$ qm agent 104 ping
{"return":{}}

Significado: El agente responde rápido. Si esto hace timeout en muchas VMs tras la actualización, podrías tener un problema host amplio o incompatibilidad QEMU/agent.

Decisión: Si las llamadas al agente cuelgan, revisa logs de QEMU y la carga del host. No asumas que es “solo el agente”—puede ser síntoma de stalls mayores.

Modos de caché de disco y barreras

Los ajustes de caché son donde la gente va para “hacerlo más rápido”. Puede funcionar. También puede salir muy mal cuando el host se cae y tu “rápido” se vuelve “corrupto”.

Tras una actualización, valida que el modo de caché y la pila de almacenamiento siguen coincidiendo con la durabilidad pretendida:

• Si confías en cache=writeback, necesitas protección fiable contra pérdida de energía y entender el riesgo.
• Si usas ZFS, no luches contra él con ajustes que crean doble caché y comportamiento de escritura impredecible.

Cambios en el modelo de CPU

Un cambio de modelo de CPU puede causar una regresión dentro del invitado (extensiones crypto, instrucciones vectoriales, temporizaciones). Las actualizaciones de Proxmox pueden desplazar valores por defecto o exponer elecciones antiguas.

Compara la configuración de CPU entre una VM “rápida” y una “lenta” (qm config). Si una usa un modelo muy genérico, puede perder características de instrucciones que benefician a tu carga.

Broma #2: La forma más rápida de mejorar rendimiento de VM es dejar de llamar a todo “la red”. No es la red—hasta que lo es.

Tres mini-historias del mundo corporativo (anonimizadas, plausibles y dolorosas)

Mini-historia 1: El incidente causado por una suposición equivocada

Actualizaron un clúster Proxmox de tres nodos en un viernes tranquilo. El ticket de cambio estaba limpio: actualización de kernel, release menor de Proxmox, reiniciar cada nodo. El domingo por la tarde el on-call recibió una alerta: el ERP “se congela aleatoriamente” 5–20 segundos varias veces por hora.

La primera suposición fue clásica: “ZFS está lento porque el ARC se reinició con el reboot, se calentará.” Esperaron. Las congelaciones continuaron, y ahora también las copias de seguridad fallaban. Alguien empezó a ajustar tunables de ZFS en producción, porque nada dice “domingo” como editar /etc/modprobe.d bajo presión.

Finalmente alguien miró journalctl -k y vio resets periódicos del controlador NVMe. Tras la actualización, el driver NVMe se comportó ligeramente distinto con esa revisión de firmware específica. Antes de la actualización el dispositivo había sido marginal pero “estable suficiente”. Después, ya no. El resultado no fue una falla limpia, sino stalls intermitentes que coincidían perfectamente con las quejas de usuarios.

La solución fue aburrida: actualizar el firmware NVMe a una versión conocida buena y mover el almacenamiento de VMs fuera del dispositivo afectado hasta la ventana de mantenimiento. El rendimiento volvió inmediatamente, y los “ajustes” de ZFS se revertieron con una disculpa a los futuros humanos.

Lección: la suposición equivocada no fue “ZFS se calentará”. Fue “las actualizaciones solo cambian software”. También cambian cómo el software habla con el hardware, y el hardware siempre escucha.

Mini-historia 2: La optimización que salió mal

Otro equipo llevaba tiempo luchando con escrituras lentas de base de datos en VMs. Alguien leyó que poner el disco de VM en cache=writeback mejora rendimiento. Lo hizo. Funcionó. Los gráficos quedaron espectaculares. La latencia bajó, el throughput subió y todos se sintieron ingenieros de almacenamiento por un día.

Luego actualizaron Proxmox. Tras la actualización, el host empezó a realizar I/O en segundo plano más agresivo durante scrubs, y la caché writeback lo ocultó hasta que ya no pudo. En hora punta surgieron picos de latencia frecuentes. “Optimizaron” más subiendo iodepth de la VM y añadiendo más vCPUs. Ahora la VM podía generar ráfagas de escritura más rápido de lo que el almacenamiento podía absorber de forma durable. Los picos de latencia empeoraron. La base de datos empezó a activar sus propios timeouts.

Culparon a la actualización. La actualización fue cómplice, no la mente maestra. El verdadero problema fue que la elección de caché cambió los modos de fallo y enmascaró el comportamiento real del almacenamiento bajo presión de escrituras sync. La mejora fue real pero inestable ante condiciones operativas.

La solución fue alinear durabilidad y rendimiento: mover la VM de base de datos a un tier de almacenamiento con rendimiento sync adecuado, asegurarse de que el SLOG no fuera cuello de botella y usar modos de caché más seguros. Conservaban buen rendimiento—pero sin la ruleta rusa.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa con Proxmox y Ceph tenía un ritual: antes de cualquier actualización, registraban tres líneas base en cada nodo—latencia I/O del host (iostat -x), estado de salud y recovery de Ceph (ceph -s) y un pequeño perfil fio en un volumen de prueba dedicado. También tenían un plan de actualización rolling con una pausa tras cada nodo para observar.

Durante una de las actualizaciones, justo después de reiniciar el nodo dos, el perfil fio mostró que la latencia se había doblado. No catastrófico, pero claramente diferente. Porque tenían una base previa, no era “quizá siempre fue así”. Era nuevo.

Pararon la actualización. Sin heroicidades. Compararon logs del kernel y encontraron un mensaje de driver de NIC que correlacionaba con más drops en la red de almacenamiento. El nodo había subido con un ajuste de offload distinto. Ceph estaba sano, pero la latencia cliente subió porque paquetes se retransmitían bajo carga.

La solución fue directa: normalizar ajustes de NIC entre nodos, verificar contadores del switch, volver a ejecutar pruebas base y continuar. Los usuarios no notaron nada. El único drama fue en la reunión de revisión de cambios, donde alguien preguntó por qué “pararon por una diferencia tan pequeña”. La respuesta fue simple: las pequeñas diferencias se convierten en grandes incidentes a las 2 a.m.

Errores comunes: síntomas → causa raíz → solución

Esta sección es intencionalmente específica. “Revisa logs” no es una solución.

1) Síntoma: load average alto, pero uso de CPU parece bajo

• Causa raíz: tareas bloqueadas por I/O (alto iowait), frecuentemente picos de latencia de almacenamiento tras la actualización.
• Solución: confirma con mpstat y iostat -x; luego identifica qué dispositivo/pool es lento; revisa scrub/resilver de ZFS o recuperación de Ceph; revisa logs del kernel por timeouts.

2) Síntoma: solo VMs Windows se volvieron más lentas, especialmente I/O de disco

• Causa raíz: desajuste del driver virtio o la VM cambió de modelo de controladora; el invitado carece de los drivers adecuados.
• Solución: verifica la controladora de la VM (qm config) y actualiza drivers virtio dentro del invitado; evita cambiar controladoras sin motivo durante actualizaciones.

3) Síntoma: congelaciones aleatorias de 5–30 segundos en múltiples VMs

• Causa raíz: timeouts/resets de NVMe, problemas de enlace SATA o regresión de firmware/driver revelada por el nuevo kernel.
• Solución: revisa journalctl -k por resets/timeouts; actualiza firmware; prueba un kernel alternativo si está disponible; migra VMs calientes fuera del dispositivo afectado.

4) Síntoma: VMs sobre Ceph lentas “a veces”, peor tras la actualización

• Causa raíz: Ceph en HEALTH_WARN, recovery/backfill compitiendo con I/O cliente; o drops en la red de almacenamiento.
• Solución: deja Ceph en HEALTH_OK; revisa estado de OSDs; revisa drops de NIC; verifica MTU y offloads; solo entonces ajusta tasas de recovery.

5) Síntoma: migraciones más lentas, acciones HA retrasadas, clúster se siente inestable

• Causa raíz: timeouts de token en corosync por jitter de red, desajuste de MTU o problemas de sincronización horaria.
• Solución: confirma logs de corosync; verifica rings; revisa contadores de NIC; valida estado del servicio de time sync; mantén corosync en una red simple y estable.

6) Síntoma: el throughput está bien, pero la latencia de cola es horrible

• Causa raíz: encolamiento y comportamiento de ráfagas; a menudo cambio de IO scheduler, amplificación de escrituras o trabajo en segundo plano (scrub/resilver, trim, backups).
• Solución: mira iostat -x await y avgqu-sz; examina tareas en segundo plano; ajusta horarios; verifica profundidades de cola; considera iothreads para discos de VM muy cargados.

7) Síntoma: drops de red aumentaron tras la actualización, pero el enlace está arriba

• Causa raíz: cambio de driver/offload de NIC, tamaño de ring buffer o problemas de negociación de bonding/LACP.
• Solución: inspecciona ip -s link; revisa offloads con ethtool; verifica estado del bond; compara con otros nodos; estandariza ajustes y firmware.

Listas de verificación / plan paso a paso

Checklist A: triaje de 20 minutos (seguro para producción)

1. Confirma versiones: pveversion -v. Anota kernel y versiones de qemu.
2. Revisa carga e iowait: uptime, mpstat -P ALL 1 5.
3. Comprueba latencia de dispositivos: iostat -x 1 5. Identifica el peor dispositivo.
4. Revisa advertencias del kernel: journalctl -k -p warning --since "2 hours ago".
5. Si ZFS: zpool status -v para scrub/resilver; zfs get para propiedades extrañas.
6. Si Ceph: ceph -s; no afines rendimiento mientras esté degradado.
7. Comprueba drops de red: ip -s link, confirma MTU y estado del bond.
8. Elige una VM lenta y compara su qm config con una VM conocida buena.

Checklist B: aislamiento de 2 horas (encontrar el subsistema)

1. Determina si la regresión es por host: compara métricas entre nodos; encuentra el “nodo malo”.
2. Si un nodo es peor, compara logs de hardware y versiones de firmware NIC/almacenamiento (no presupongas uniformidad).
3. Ejecuta un pequeño fio de solo lectura en una ruta segura para comparar latencia entre nodos.
4. Inspecciona interrupciones y carga de softirq si se sospecha red (/proc/interrupts, mpstat).
5. Comprueba trabajos en segundo plano: ZFS scrub/resilver; recovery de Ceph; backups; trim/discard.
6. Si es relacionado con kernel, considera arrancar con el kernel anterior (con plan de rollback) para confirmar causalidad.

Checklist C: endurecer después de arreglarlo (para que la próxima actualización no muerda)

1. Registra líneas base (distribuciones de latencia, no solo promedios): iostat, un pequeño perfil fio, métricas de latencia de VMs.
2. Estandariza offloads/MTU de NIC entre nodos; documéntalo en tu proceso de construcción.
3. Programa scrubs/resilvers/backups para evitar ventanas pico de negocio.
4. Mantén firmware en gestión de ciclo de vida: NVMe, NIC, BIOS, HBA.
5. Mantén un nodo canario de actualización; hazlo primero y obsérvalo 24–48 horas si es posible.
6. Escribe el perfil hardware de VM conocido-bueno (tipo de controladora, modo de caché, modelo de CPU) y aplícalo consistentemente.

Preguntas frecuentes

1) “Todo está más lento tras la actualización.” ¿Suele ser Proxmox en sí?

Normalmente es el kernel/pila de almacenamiento/red lo que cambió bajo Proxmox. Proxmox es el punto de integración, por eso recibe la culpa. Empieza por iowait, latencia de disco y drops de NIC.

2) ¿Cómo digo rápido si es almacenamiento o CPU?

mpstat es tu amigo. Alto %iowait apunta a almacenamiento. Alto %usr/%sys con bajo iowait apunta a saturación de CPU o trabajo del kernel. Luego confirma con iostat -x.

3) ¿Un scrub/resilver de ZFS puede realmente ralentizar tanto las VMs?

Sí, especialmente en pools HDD o pools con un vdev estresado. Compite por I/O y puede elevar la latencia. El efecto depende de la carga; las bases de datos lo notan inmediatamente.

4) Ceph está en HEALTH_WARN pero “funciona en su mayoría”. ¿Debo tratarlo como causa?

Sí. “Funciona en su mayoría” es cómo los sistemas distribuidos te atraen hacia la complacencia. Recovery/backfill y PGs degradados pueden causar latencia visible por usuarios.

5) Tras la actualización, el rendimiento de disco de las VMs bajó. ¿Debo cambiar cache a writeback?

No como primer movimiento. Puede mejorar velocidad pero cambia la semántica de durabilidad. Arregla la latencia subyacente primero (salud de dispositivo, layout del pool, salud de Ceph). Si cambias el modo de caché, hazlo con aceptación de riesgos.

6) ¿Por qué veo load average alto pero las CPUs están ociosas?

La carga incluye tareas en sleep ininterrumpible (a menudo I/O). Así que puedes tener carga alta y CPUs ociosas si el sistema espera por almacenamiento.

7) ¿Un desajuste de MTU puede aparecer como “almacenamiento lento”?

Absolutamente. Si tu red de almacenamiento pierde tramas grandes o las fragmenta de manera impredecible, verás retransmisiones y jitter. Los protocolos de almacenamiento son sensibles a eso.

8) ¿Debo revertir el kernel inmediatamente?

Si tienes evidencia sólida de que la regresión es por kernel/driver (nuevos resets/timeouts, mensajes de hang de NIC, comparativa antes/después), revertir es una mitigación válida. Confírmalo con logs y una prueba controlada. No reviertas a ciegas sin entender riesgos y parches de seguridad.

9) ¿Es normal que el rendimiento cambie tras un reinicio porque las cachés están frías?

Algo de cambio es normal—ARC y page cache se calientan. Pero rendimiento persistentemente lento horas después, o stalls periódicos, no es “cache fría”. Eso es un cuello de botella real.

10) ¿Cómo evito esto la próxima vez?

Registra métricas base antes de las actualizaciones, usa un nodo canario, mantén firmware consistente y deja de tratar almacenamiento y redes como “configuradas y olvidadas”. Ellas recuerdan.

Conclusión: pasos siguientes que realmente funcionan

Si Proxmox se volvió más lento tras una actualización, no empieces ajustando perillas de VM. Comienza demostrando qué subsistema está haciendo esperar a todo el mundo.

1. Clasifica el cuello de botella: CPU vs almacenamiento vs red. Usa mpstat y iostat, no corazonadas.
2. Comprueba trabajo en segundo plano y problemas de salud: resilvers/scrubs de ZFS, recovery de Ceph, inestabilidad de corosync.
3. Lee las advertencias del kernel: timeouts y resets de driver son incidentes de rendimiento disfrazados.
4. Compara configuraciones y líneas base: encuentra qué cambió, mídelo y decide con base en evidencia.
5. Una vez estable, endurece: registra líneas base, estandariza firmware y ajustes de NIC/almacenamiento y sigue una ruta canaria de actualización.

Haz esos pasos y normalmente encontrarás la causa antes de que la próxima reunión de estado se invite sola a tu calendario.