cazador: evidencia a favor de la hipótesis de presión de memoria

Al montar otro banco, la carga estaba en 3,34 (contra 0,13 de las cuatro cazas)
porque otro agente arrancó un cargo, y kswapd0 consumía CPU con CERO memoria
libre: recuperación de páginas bajo presión. Cada corrida mapea un libxul de
227 MB.

Es exactamente la condición que las cazas NO tenían y que los dos bancos con
cuelgues SÍ. No es prueba —el estado de aquellas ventanas no se reconstruye—
pero es la primera pista concreta, y cambia dónde buscar: cazar BAJO PRESIÓN de
memoria, no con la máquina ociosa.
This commit is contained in:
Sergio
2026-09-08 14:17:21 +00:00
parent 2e496d62e0
commit 8c1378cb1f
@@ -28,6 +28,15 @@
# · Sobrevive la hipótesis que no se puede probar retroactivamente: contención transitoria de otra
# cosa en la máquina (es compartida con otros agentes) durante esas dos ventanas.
#
# ⚠ EVIDENCIA A FAVOR DE ESA HIPÓTESIS, VISTA DESPUÉS (2026-09-08): al ir a montar OTRO banco, la
# carga estaba en 3,34 (contra 0,13 de las cazas) porque otro agente había arrancado un `cargo`,
# y `kswapd0` aparecía consumiendo CPU con CERO memoria libre — o sea recuperación de páginas
# bajo presión. Cada corrida mapea un `libxul` de 227 MB; con la caché apretada, eso es
# exactamente la condición que las cuatro cazas NO tenían y que los dos bancos con cuelgues SÍ.
# No es prueba —no se puede reconstruir el estado de aquellas dos ventanas— pero es la primera
# evidencia que apunta a algo concreto: **cazar bajo presión de memoria, no con la máquina
# ociosa**. Se puede forzar corriendo el cazador mientras algo grande compila.
#
# ══ PARA QUÉ SIRVE ENTONCES ════════════════════════════════════════════════════════════════════
# Para que la PRÓXIMA vez que aparezca, se capture en el acto en vez de empezar de cero: `wchan`,
# `syscall` y `state` de cada proceso (distinguen espera de disco de espera de lock), memoria y