fix: el checklist normalizaba un swap alto que no era normal
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.
This commit is contained in:
@@ -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
|
||||
|
||||
+24
-7
@@ -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 @@
|
||||
<H>Sistema</H>
|
||||
<Li><strong style={{color:C.t1}}>CPU por núcleo</strong> — uso individual de cada núcleo. Calculado desde <Code>/proc/stat</Code>, equivalente a htop.</Li>
|
||||
<Li><strong style={{color:C.t1}}>RAM</strong> — memoria realmente usada por procesos, excluyendo caché del kernel (mismo cálculo que htop).</Li>
|
||||
<Li><strong style={{color:C.t1}}>SWAP</strong> — memoria de intercambio en uso. Un valor alto sostenido (como el de Fulcrum) es normal pero conviene monitorizarlo.</Li>
|
||||
<Li><strong style={{color:C.t1}}>SWAP</strong> — memoria de intercambio en uso. Debería estar cerca de cero. Un valor alto <em>no</em> 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 <Code>db_mem</Code> en la configuración de Fulcrum — se sube para acelerar la sincronización inicial y es fácil olvidarse de bajarlo.</Li>
|
||||
<Li><strong style={{color:C.t1}}>Procesos destacados</strong> — los procesos que más memoria consumen en tiempo real.</Li>
|
||||
<H>Logs en tiempo real</H>
|
||||
<P>Panel de logs de Bitcoin Core y Fulcrum. Muestra las últimas 80 entradas con filtrado por nivel (todos / warn / error). Pulsa ↻ para actualizar.</P>
|
||||
|
||||
Reference in New Issue
Block a user