RAM efectiva y N-1 — 19 octubre 2026¶
Usuario autorizó aplicar las mejoras y reducir RAM con varios agentes. La coordinación cambia únicamente balloon de VM171/208; un agente contrasta consumos, persistencia y alternativas de solo lectura. Sin reinicios, apagados, drop_caches, cambios ARC adicionales ni recortes de límites LXC.
Método y recuperación¶
scripts/maintenance/tune-vm-balloon.py comprueba ubicación real, QGA,
MemAvailable y PSI antes de cada cambio. Máximo512MiB por paso, disponible
estimado posterior >=1024MiB y PSI full avg10/avg300 <0,5%. Observa cuatro muestras
tras aplicar; revierte si disponible <768MiB, PSI10 >=2%, PSI300 >=1%, nuevo OOM
o más64MiB de swap-out. El intercambio histórico no se presenta como presión
actual. Cuatro fixtures comprueban admisión, límites, rollback y orden de
restauración. No constituyen prueba de carga doméstica prolongada.
Proxmox instalado confirma en QemuServer.pm que shares=0 permite controlar
balloon manualmente y que el arranque envía conf.balloon al invitado. Por eso
el target queda persistente en la configuración de Proxmox sin reiniciar.
memory conserva el máximo anterior para recuperación explícita: no se
presenta como máximo reducido ni como RAM liberada automáticamente adicional.
Registros previos y muestras privados, modo0600:
~/.local/state/homelab/ram-tuning/VMID-FECHA.json. Para restaurar VM171 al estado
anterior: en su propietario real, qm set 171 --shares 0,
qm set 171 --balloon 6144, qm set 171 --delete shares y finalmente
qm set 171 --balloon 4608. En VM208, los valores originales son efectivo8192,
shares ausente, mínimo6144; mismo orden, sustituyendo VMID/valores. Primero
recuperar efectivo y después restaurar política/mínimo evita un recorte
transitorio al antiguo mínimo. Comprobar antes que nadie haya cambiado la
configuración desde el ensayo. La restauración exige observar nuevamente
memoria/PSI y salud, no basta el retorno de qm.
Home Assistant, VM171 en pmx51¶
Dos pasos de256MiB: efectivo6144→5888→5632MiB. Queda memory=6144,
balloon=5632, shares=0. Sin reinicio ni OOM. En el segundo paso RSS del
proceso QEMU5917→5687MiB: unos230MiB físicos medidos. No se dispone de RSS
inicial comparable para atribuir exactamente512MiB físicos a ambos pasos.
Muestra20:39:29UTC: efectivo5632, RSS5697, MemAvailable1209MiB, swap466MiB y PSI full10/300=0/0,07%. La swap antes del primer paso era233MiB; hubo reclaim transitorio y desplazamiento a zram. Por ese disponible no se reduce más: otro paso256 dejaría menos de1GiB estimado dentro del invitado.
VM208 en pmx50¶
La copia de originales se conserva en marcha. Se esperó al final del exportador Paperless y docker save, y al descenso de PSI300. Las primeras propuestas 8192→7680 fueron rechazadas antes de cambiar configuración por PSI300 0,58/0,53%. No se relajó la guarda para conseguir el recorte.
Ensayo20:42:37UTC admitido: efectivo8192, RSS8200, disponible2824,
swap3252MiB, PSI full10/300=0,01/0,47%. Target7680MiB aplicado y observado
en las cuatro muestras. Última20:43:30UTC: RSS7691MiB (509MiB físicos menos),
disponible2325MiB, swap3265MiB, PSI full10/300=0,06/0,45%, OOM0. Incremento
swap-out acumulado3468páginas, unos13,5MiB. Sin reinicio ni rollback.
Queda memory=8192, balloon=7680, shares=0; efectivo7,5GiB.
Seguimiento20:47:35UTC: RSS7706, disponible2400MiB, swap3343MiB, PSI full10/300=0,12/0,34%, OOM0. HAOS20:45:01UTC: RSS5682, disponible1245MiB, swap503MiB, PSI0/0,01%, OOM0. La swap crece durante la copia/reclaim aunque no hay PSI elevado sostenido; se conserva observación y no se hacen más recortes para forzar una cifra de margen.
En total los targets efectivos bajan1GiB entre ambas VMs. La ganancia RSS
demostrada con comparables es509MiB de VM208 más230MiB del segundo paso HAOS;
no se inventa una medida física del primer paso. memory.current del cgroup
VM208 incluso subió8197→8227MiB por páginas de archivo: no se usa ese contador
como RSS físico ni se suma su caché como ahorro adicional.
Capacidad y límites¶
Normalidad20:40UTC, después del recorte HAOS y antes del de VM208: 10HA migrables10575MiB RAM+swap, destino pmx50 disponible13439MiB, reserva2048MiB y margen sin balloon +816MiB. Es una muestra, no una garantía para picos; no se atribuye toda la variación al recorte RAM. Límites migrables19328MiB. Siguen excluidos los estrictos110/172/217/218 y servicios fuera de HA; las parejas C0 tienen comprobación separada.
Tras ambos recortes, lectura20:44UTC: HA migrables11103MiB, disponible destino 13525MiB y margen +374MiB después de reservar2048MiB, sin ningún crédito balloon. Ambos hosts PSI full300=0. El consumo paralelo varía; liberar RSS demostrado no equivale a ganar el mismo delta en cada presupuesto de cluster. Las muestras+816/+374MiB demuestran que sigue faltando holgura para picos.
No se recortan caps LXC para aparentar ahorro: no reservan la RAM declarada. Lectura del agente20:41UTC: anon residente Vera2638MiB, observa1515, personal735, Jellyfin254; en50, RAG757 y Homelable173MiB. Reducir sus caps no liberaría automáticamente esos consumos y puede causar reclaim/OOM. Tampoco se apagan servicios ni se elimina caché para producir un OK temporal.