From d3e204d396cbb8a72a4a7f5add5307a6c768aa5a Mon Sep 17 00:00:00 2001 From: Aitor Date: Sat, 8 Aug 2026 15:58:26 +0200 Subject: [PATCH] fix: el checklist normalizaba un swap alto que no era normal MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Decía 'Normal en nodos con índice completo' ante un swap al 99%. En el caso real que lo destapó no lo era: Fulcrum tenía db_mem a 16 GB, más de lo que cabe en la máquina, y el sistema llevaba quince días sin margen ante un pico de memoria. Ese mensaje es la razón de que se ignorara tanto tiempo. Umbral del 95% al 50%, error por encima del 80%, detección del caso 'swap alto con RAM libre' (firma de memoria sobrerreservada), y el aviso apunta a db_mem e incluye el comando para ver quién ocupa el swap. --- CHANGELOG.md | 16 ++++++++++++++++ dashboard.html | 31 ++++++++++++++++++++++++------- 2 files changed, 40 insertions(+), 7 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index b663997..fb26d7f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -12,6 +12,22 @@ y el versionado sigue [Versionado Semántico](https://semver.org/lang/es/): --- ## [1.13.0] — 2026-08-08 +### Cambiado +- **El checklist decía que un swap alto era "normal en nodos con índice + completo".** No lo es, y decirlo hace que se ignore durante semanas un + síntoma con causa y con arreglo. El caso que lo cambió: swap al 99% con 18 GB + de RAM libre, porque Fulcrum tenía `db_mem` a 16 GB — más de lo que cabe en + la máquina junto al resto de servicios. Con el swap lleno el sistema se queda + sin margen y, ante un pico, el OOM killer elige él a quién mata. + - El umbral baja del 95% al 50%, que es cuando conviene mirarlo y no cuando + ya es tarde, y pasa a estado de error por encima del 80%. + - Si el swap sube **teniendo RAM libre**, el aviso lo señala: es la firma de + un servicio con más memoria reservada de la que cabe, no de presión real. + - Apunta al sospechoso habitual (`db_mem` de Fulcrum, que se sube para + acelerar la sincronización inicial y es fácil olvidarse de bajar) e incluye + el comando para ver qué proceso ocupa el swap. +- Misma corrección en la explicación de SWAP de los DOCS. + ### Añadido - **Nueva comprobación: direcciones que quedan vinculadas entre sí.** Era el hueco de fondo del analizador: medía la privacidad desde el lado de quien diff --git a/dashboard.html b/dashboard.html index fa2686b..9b3b875 100644 --- a/dashboard.html +++ b/dashboard.html @@ -3030,14 +3030,31 @@ } // ── 5. Swap alto ────────────────────────────────────────────── - if (sysData?.swap) { - const pct = sysData.swap.percent || 0; + // Este aviso decía antes que un swap alto era "normal en nodos con + // índice completo". No lo es, y decirlo hace que se ignore durante + // semanas un síntoma que sí tiene causa y sí tiene arreglo. El caso + // real que lo cambió: swap al 99% con 18 GB de RAM libre, porque + // Fulcrum tenía db_mem configurado a 16 GB — más de lo que cabe en la + // máquina junto al resto de servicios. Con el swap lleno, el sistema + // se queda sin margen y ante un pico actúa el OOM killer, que elige + // él a quién mata. + // + // El umbral baja a 50% porque a partir de ahí ya conviene mirarlo, no + // cuando queda un 5% libre y es tarde. + const swapStats = sysData?.swap || (sysData?.ram ? { percent: sysData.ram.swap_percent, used_gb: sysData.ram.swap_used_gb } : null); + if (swapStats) { + const pct = swapStats.percent || 0; + const ramLibre = sysData?.ram?.free_gb; + // Swap ocupado teniendo RAM libre es la firma de un servicio con más + // memoria reservada de la que cabe: el kernel apartó páginas y no las + // devuelve por su cuenta. + const conRamLibre = typeof ramLibre === "number" && ramLibre > 2 && pct > 50; results.push({ id:"swap_usage", label:"Uso de SWAP", - status: pct > 95 ? "warn" : "ok", - detail: pct > 95 - ? `SWAP al ${pct}%. Fulcrum está usando casi toda la memoria de intercambio. Normal en nodos con índice completo, pero monitoriza que el OOM Killer no actúe.` - : `SWAP al ${pct}%. Uso normal.`, + status: pct > 80 ? "error" : pct > 50 ? "warn" : "ok", + detail: pct > 50 + ? `SWAP al ${pct}% (${swapStats.used_gb || "?"} GB).${conRamLibre ? ` Y eso ocurriendo con ${ramLibre} GB de RAM libre, que es la señal típica de un servicio con más memoria reservada de la que cabe en la máquina.` : ""} Con el swap lleno el sistema se queda sin margen: ante un pico de memoria actúa el OOM killer, y elige él qué proceso mata — puede tocarle a bitcoind o a Fulcrum en mitad de una escritura. El sospechoso habitual es \`db_mem\` en la configuración de Fulcrum: acelera la sincronización inicial y mucha gente lo sube para eso y no lo vuelve a bajar. Para ver quién ocupa el swap: for p in /proc/[0-9]*; do s=$(awk '/VmSwap/{print $2}' $p/status 2>/dev/null); [ -n "$s" ] && [ "$s" -gt 0 ] && echo "$s KB $(cat $p/comm)"; done | sort -rn | head` + : `SWAP al ${pct}%. Sin presión de memoria.`, }); } @@ -6714,7 +6731,7 @@ Sistema
  • CPU por núcleo — uso individual de cada núcleo. Calculado desde /proc/stat, equivalente a htop.
  • RAM — memoria realmente usada por procesos, excluyendo caché del kernel (mismo cálculo que htop).
    • -
  • SWAP — memoria de intercambio en uso. Un valor alto sostenido (como el de Fulcrum) es normal pero conviene monitorizarlo.
    • +
  • SWAP — memoria de intercambio en uso. Debería estar cerca de cero. Un valor alto no es normal aunque se repita: significa que algún servicio tiene reservada más memoria de la que cabe en la máquina, y deja al sistema sin margen ante un pico. Si sube teniendo RAM libre, el sospechoso habitual es db_mem en la configuración de Fulcrum — se sube para acelerar la sincronización inicial y es fácil olvidarse de bajarlo.
  • Procesos destacados — los procesos que más memoria consumen en tiempo real.
    • Logs en tiempo real

    Panel de logs de Bitcoin Core y Fulcrum. Muestra las últimas 80 entradas con filtrado por nivel (todos / warn / error). Pulsa ↻ para actualizar.