Memoria comprimida en macOS: 47 GB ocultos detrás de un RSS de 264 MB
Un proceso de automatización social en macOS consumió 47 GB de memoria comprimida sin que el RSS o Activity Monitor lo revelaran, provocando que la publicación de contenidos se detuviera durante 24 h. El autor creó un job launchd para monit
En un día sin publicaciones sociales, el autor descubrió que el proceso dasd (Duet Activity Scheduler) tenía 264 MB reportados por RSS pero 46 GB de memoria comprimida, totalizando 47 GB reservados.\n\nEl sistema había usado 37 GB de swap, lo que impidió que Playwright pudiera iniciar Chrome dentro de los 180 s permitidos, y el agente iii (agentmemory) añadía 4 GB por hora.\n\n### ¿Por qué RSS no muestra la verdad?\nRSS muestra solo las páginas físicas en uso. macOS comprime páginas poco usadas en un espacio de 1 GB de memoria física, y esas páginas comprimidas no aparecen en RSS ni en la columna “Memory” de Activity Monitor.\n\n### Solución: monitorización con launchd\nEl autor diseñó un script mem-hog-guard.sh que se ejecuta cada 10 minutos con prioridad baja. El flujo es:\n1. Top con -o mem y cmprs para leer MEM y CMPRS.\n2. Si dasd supera 3072 MB, se envía killall dasd y launchd lo reinicia inmediatamente.\n3. Si iii supera 4096 MB, se envía SIGTERM, espera 2 s, y luego SIGKILL seguido de kickstart -k.\n4. Si otros procesos superan 6144 MB, solo se envía una notificación a Discord.\n5. Se evita reiniciar procesos críticos (kernel_task, WindowServer, launchd, loginwindow, Finder).\n6. Se mantiene un archivo de bloqueo (shlock) para prevenir ejecuciones simultáneas.\n7. Se registra el uso de swap con sysctl vm.swapusage y se notifica vía Discord.\n\n### Impacto y rendimiento\nEl script corre con Nice=10 y LowPriorityIO=true, por lo que su impacto sobre la productividad es nulo. La detección y reinicio automáticos garantizan que los procesos de publicación social se ejecuten en los momentos óptimos (7 AM, 12 PM, 9 PM) sin intervención humana.\n\n### Por qué importa\nEn entornos donde la automatización depende de procesos de larga duración, una memoria comprimida oculta puede llevar a fallos silenciosos que se descubren solo al día siguiente. La solución presentada demuestra que, con una monitorización adecuada y políticas de reinicio selectivo, se puede mantener la estabilidad sin sacrificar la experiencia del usuario ni interrumpir procesos críticos.
