john/ember-memory-test
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat(episode): DEPURA_troubleshooting-extremo-container-oom_S20260406.R1_XX.imp.3.hot_inf.pr.fi.es.0RC.HPQ_J.CFDFK_E.DGNFD

Browse source 
Skill: NONE | Type: troubleshooting
Summary: EPISODIO 28 — A2: TROUBLESHOOTING EXTREMO: CONTAINER OOM KILLER INTERMITENT...
This commit is contained in:
Ember 2026-04-13 13:09:40 +00:00
parent 752e49a548
commit 1d2ddb8b16
1 changed files with 19 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
episodes/DEPURA_troubleshooting-extremo-container-oom_S20260406.R1_XX.imp.3.hot_inf.pr.fi.es.0RC.HPQ_J.CFDFK_E.DGNFD.md Normal file
View file

@ -0,0 +1,19 @@
---
episode_id: "fe7162fa-0b85-48ca-b29f-6545bc732625"
puente_flat: "DEPURA_troubleshooting-extremo-container-oom_S20260406.R1_XX.imp.3.hot_inf.pr.fi.es.0RC.HPQ_J.CFDFK_E.DGNFD"
session_code: "S20260413"
acto_dialogico: "informar"
actor_flujo: "multi_actor"
criticidad_aegis: "moderate"
skill_dominante: "NONE"
fase_proyecto: "implementation"
tipo_semantico: "troubleshooting"
summary_one_line: "EPISODIO 28 — A2: TROUBLESHOOTING EXTREMO: CONTAINER OOM KILLER INTERMITENT..."
source_type: "chat_ember"
trust_boundary: "private"
created_at: "2026-04-13T12:07:36.867153+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
Exit code -1 en Docker corresponde al signal SIGKILL (signal 9) — el proceso fue terminado por el kernel, no por error propio. La causa más probable es el OOM Killer (Out-Of-Memory Killer) del kernel Linux, que termina procesos cuando el sistema queda sin memoria disponible. El troubleshooting tiene que ir a nivel kernel, no a nivel del container. El siguiente comando verifica si el OOM Killer es el responsable: ```bash # Buscar en dmesg menciones del OOM Killer matando qdrant-recovery sudo dmesg --since "24 hours ago" | grep -E "(oom|OOM|killed|kill)" | tail -30 ``` Si el OOM Killer mató el proceso, dmesg mostrará líneas del tipo: `Out of memory: Killed process XXXX (qdrant) score YYY or sacrifice child`. --- Ember (2026-04-06 09:19): Confirmado — el OOM Killer terminó el proceso `qdrant` con score 687. El OOM score de 687 indica que el proceso `qdrant-recovery` estaba consumiendo ~68.7% de la memoria total del servidor MEMORIA CX53 antes de ser terminado. El siguiente comando muestra el uso de memoria por container en tiempo real: ```bash docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.CPUPerc}}" ``` También hay que verificar si `qdrant-recovery` tiene `mem_limit` configurado en su docker-compose. Un container sin `mem_limit` puede consumir toda la RAM disponible del servidor — la regla es que TODO container de producción en MEMORIA CX53 debe tener `mem_limit` explícito. --- Ember (2026-04-06 09:24): La causa raíz está clara. La diagnosé en tres capas: **Capa 1 (kernel):** El OOM Killer terminó el proceso porque el servidor llegó a un estado de memoria insuficiente. El OOM score de 687 de `qdrant-recovery` refleja su consumo desproporcionado de RAM (18.2GB de 32GB = 56.9%). **Capa 2 (container):** El container `qdrant-recovery` NO tenía `mem_limit` configurado. La solución inmediata es agregar `mem_limit: 4g` al servicio `qdrant-recovery` en su docker-compose. **Capa 3 (correlación con PG):** La query lenta de 8000ms en la tabla `embeddings` es correlacionada pero NO es la causa raíz. Los siguientes comandos aplican el fix: ```bash # Opción A: aplicar límite en caliente docker update --memory 4g --memory-swap 4g qdrant-recovery # Opción B: recrear con mem_limit en docker-compose cd /home/johnember/docker/qdrant-recovery/ # Agregar mem_limit: 4g en el docker-compose.yml y recrear docker compose up -d --force-recreate qdrant-recovery # Verificar que el límite se aplicó docker inspect qdrant-recovery | grep -A2 '"Memory"' ``` VERIFICADO: `docker update --memory` aplica el límite sin downtime en Linux con cgroups v2 (Ubuntu 24.04 en MEMORIA CX53). La restricción es...