N−1: ventana de dos horas completada, 22 octubre 2026¶
La envolvente observada sigue siendo negativa: −3,81 GiB, tras reservar 2 GiB, con los máximos por huésped. La comparación usando el mayor total de una ronda también es negativa: −2,02 GiB. No se ha admitido capacidad N−1, ni ejecutado migración, failover o estrés. El +681 MiB instantáneo del 21 oct pertenece a otro boot y no dimensiona esta ventana caliente.
Qué se midió¶
Demanda en origen pmx51: 08:51:07.770301–10:51:07.786230 CEST,
boot 86184726…, diez migrables. Se cerró el mismo receptor, sesión 30270,
con exit 0 real, 121 muestras y 123 frames. Terminal, recibo y JSONL privados
quedaron ligados por hashes externos; el reductor mantenido y una revisión
independiente reprodujeron el resultado. No se reconstruyó un terminal.
Cada ronda toma dos pasadas consecutivas y conserva por huésped la fila de mayor RAM+swap. Su suma no es una medida atómica simultánea. Los máximos por huésped pueden corresponder a rondas distintas. LXC usa cgroup memory.current más memory.swap.current; VM171 usa VmRSS más VmSwap del proceso. No hay crédito por balloon, ni una reducción de límites ejecutada.
| Recurso | RAM MiB de su fila máxima | Swap MiB de esa fila | Total MiB | Ronda |
|---|---|---|---|---|
| 100 | 4445.37 | 1040.06 | 5485.43 | 16 |
| 123 | 139.60 | 0.00 | 139.60 | 62 |
| 155 | 121.72 | 0.00 | 121.72 | 29 |
| 171 | 6169.27 | 12.42 | 6181.69 | 0 |
| 212 | 129.72 | 19.73 | 149.45 | 34 |
| 213 | 122.34 | 1.43 | 123.77 | 47 |
| 214 | 206.10 | 8.74 | 214.84 | 48 |
| 215 | 377.62 | 30.70 | 408.32 | 13 |
| 216 | 150.94 | 4.65 | 155.59 | 27 |
| 220 | 3047.69 | 197.82 | 3245.51 | 99 |
La suma de máximos no coincidentes es 16.225,9296875 MiB; el mayor total de una ronda es 14.390,6640625 MiB (ronda16). CPU máximo del observador por ronda: 26,38 ms; lectura máxima 39,05 ms. Los 60 s entre muestras dejan hasta59,985 s entre lecturas sin observar: no acotan picos intermedios ni demanda de arranque.
Oferta del destino pmx50: una sola query_range al histórico ya cacheado de
Prometheus, ventana ligada a los extremos reales de demanda, paso15s. No se
forzaron scrapes. UUID y btime de ambos hosts coinciden PRE/POST, y el boot
cacheado es constante y coincide con el nativo. Destino a00208e6…,
btime1792641755; origen861, btime1792439931. El receptor CT217, su dueño y la
identidad de Prometheus mantuvieron las guardas revisadas.
Hay 480/481 puntos usables por host: se excluye el primer valor porque su scrape precede a la ventana. No hay puntos ausentes, stale, up0 ni saltos de muestras únicas mayores de30s. La cobertura se conserva como parcial: pmx50 deja7,553s al inicio y7,463s al final sin muestras; separación máxima entre scrapes15,003s. No se rellena ningún borde ni se trata un hueco como cero.
Cálculo descriptivo¶
| Cantidad | Bytes |
|---|---|
| Menor MemAvailable del destino observado | 15.067.607.040 |
| Suma de máximos por huésped, no coincidentes | 17.014.120.448 |
| Reserva | 2.147.483.648 |
| Envolvente conservadora | −4.093.997.056 |
| Mayor total de una ronda | 15.089.704.960 |
| Comparación con ese total y la misma reserva | −2.169.581.568 |
La primera diferencia equivale a−3904,34MiB/−3,8128GiB; la segunda, a−2069,07MiB/−2,0206GiB. Son diferencias entre extremos observados, no un instante simultáneo de déficit probado. La cobertura parcial y los picos no observados impiden convertirlas en una garantía. Ambas desaconsejan usar el antiguo resultado instantáneo positivo como admisión de capacidad.
Siguiente mejora concreta¶
Una lectura posterior, 12:12 CEST, de los mismos cgroups100/220 con boot, PID/start, owner y cgroup PRE/POST fijados distingue estas categorías:
| Recurso | Anon MiB | File MiB | Inactive file MiB | Swap MiB |
|---|---|---|---|---|
| CT100 | 2979,14 | 306,25 | 182,30 | 26,37 |
| Jellyfin220 | 374,21 | 2167,50 | 1932,72 | 187,40 |
Las categorías se solapan y la lectura no es atómica. PSI some/full avg10/60/300 es0 en esa muestra; no describe toda la ventana anterior. No es una descomposición retrospectiva de las filas máximas ni prueba cuántos bytes serían recuperables al fallar un nodo. No se resta file/inactive/slab del presupuesto, no se vacían cachés ni se bajan límites.
El inventario identifica CT100 como Vera/OpenClaw, trabajo paralelo del usuario:
queda excluido de investigar procesos, configuración o recortes. Jellyfin sigue
incluido, con una sola instancia activa y recuperación HA. Su caché de archivos
se distingue de memoria anónima antes de cualquier propuesta de dimensionado.
Recibo nminus-memory-categories-ksc0r5zr/native.json, SHA256
<REDACTED>.
VM171 se conserva: este análisis no autoriza shell en HAOS ni herramientas que eludan su perfil. Vera/RAG y los trabajos paralelos del usuario quedan fuera de los recortes. Los cuatro recursos estrictos110/172/217/218, VM208 sin HA y las dependencias comunes NAS/router/quórum siguen requiriendo análisis por servicio. La causa de los resets de pmx50 permanece abierta. No se cambian watchdog, RAM, BIOS, reglas HA, invitados ni programación para mejorar este indicador.
Decisión del receptor: VM208, 22 octubre 19:59–20:02 CEST¶
No se inicia otra campaña ni se recortan invitados. La lectura puntual de PVE
sitúa VM208 en pmx50, running; mismo boot 51c5b68b… que el cierre Jellyfin.
Sólo se leyeron metadatos PVE y /proc, sin inspeccionar aplicaciones.
| Dato observado | Resultado | Consecuencia |
|---|---|---|
| Siete migrables pequeños, filas máximas de la campaña anterior | unos 1313 MiB / 1,28 GiB | Retirarlos todos tampoco cubre la envolvente conservadora de 3,81 GiB; algunos sostienen entrada, acceso o secretos. No se propone apagarlos. |
| VM208, proceso QEMU en el host, 19:59/20:00 | RSS 7,705 GiB; PSS 7,697 GiB; privados dirty 7,686 GiB; swap 0 | Tiene peso suficiente para estudiar un perfil degradado, pero RSS no es una promesa de ahorro ni autorización de apagado. |
| PVE VM208, 20:01 | máximo 8192 MiB, balloon configurado y actual 7680 MiB; shares 0 | Los 7,5 GiB efectivos ya están aplicados. Máximo y objetivo distintos no demuestran deriva ni ahorro nuevo. |
Linux de VM208, 20:02, boot 74b05e84… |
MemAvailable 1,719 GiB; swap usado 1,437 GiB | No acredita poder retirar otros 3–4 GiB mediante balloon sin presión. No se cambia el objetivo. |
Estos valores posteriores pertenecen a otro boot del receptor que la campaña 08:51–10:51. No se suman a aquella oferta para producir un supuesto PASS N−1. El déficit conservador es un resultado del modelo, no una falta física de RAM probada en un instante ni una orden de comprar exactamente esa cantidad.
El perfil con VM208 temporalmente apagada sigue sin admitir: se ha solicitado la preferencia funcional del usuario y no hay respuesta registrada. Incluso si se acepta el downtime de Immich/Paperless y otras aplicaciones, eso no acepta perder trabajo. Hunter/Scanner conservan un límite conocido: despliegue antiguo sin drain lossless de pendientes/en vuelo; cola cero no prueba reposo. No hay orden de apagado, recreación o migración automática.
La fuente actual de Jellyfin220 usa datos locales y medios NFS directos; el camino Caddy/PocketID observado tampoco pasa por208. Eso no demuestra autonomía de todas las funciones de HA o herramientas de Vera. Las dependencias históricas Leina/TTS y multimedia del ADR0027 requieren reconciliación específica, sin intervenir en el trabajo del usuario. La decisión queda entre capacidad suficiente para conservar208 o un perfil funcional explícito con conservación segura de trabajos; no más restores para resolver esta cuestión.
Evidencia y reproducción¶
nminus-demand-renewed-s725iu0d/reduction-native.json, SHA256<REDACTED>.- JSONL
<REDACTED>; terminal<REDACTED>; recibo<REDACTED>. nminus-offer-renewed-bound-fzmfwhpg/closure.json, SHA256<REDACTED>.calculation.json, SHA256<REDACTED>; revisión independiente<REDACTED>.
Los artefactos completos permanecen privados. El reductor documentado en
scripts/nminus-observation/README.md es local y requiere los pins de campaña;
no repite observación ni consulta oferta. El driver de oferta dispone de marca
exclusiva de intento y ya terminó: no volver a ejecutarlo para rellenar bordes.