ember-memory-test/episodes/DEPURA_troubleshooting-extremo-container-oom_S20260406.R1_XX.imp.3.hot_inf.pr.fi.es.0RC.HPQ_J.CFDFK_E.DGNFD.md

episode_id	puente_flat	session_code	acto_dialogico	actor_flujo	criticidad_aegis	skill_dominante	fase_proyecto	tipo_semantico	summary_one_line	source_type	trust_boundary	created_at	relectura_tagged	forgejo_commit_sha
fe7162fa-0b85-48ca-b29f-6545bc732625	DEPURA_troubleshooting-extremo-container-oom_S20260406.R1_XX.imp.3.hot_inf.pr.fi.es.0RC.HPQ_J.CFDFK_E.DGNFD	S20260413	informar	multi_actor	moderate	NONE	implementation	troubleshooting	EPISODIO 28 — A2: TROUBLESHOOTING EXTREMO: CONTAINER OOM KILLER INTERMITENT...	chat_ember	private	2026-04-13T12:07:36.867153+00:00	false	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...