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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user