The 46GB Leak Your RSS Alert Cannot See: macOS Compressed Memory Breaks Threshold Monitoring

A developer running an automated posting stack on macOS lost a full day of output on August 9, 2026, and `top -o mem` reported nothing wrong for the duration ^[1][2]. The process responsible, `dasd`, was carrying 46GB of compressed memory behind a 264MB resident set, roughly 178 times its RSS, which is exactly why it never entered the top 20 of an RSS-descending list ^[4][1].

The failure presented as an application bug. The Playwright instance managed by Claude Code looked alive, but `launchPersistentContext` had been timing out at 180 seconds, repeatedly ^[5]. The first diagnostic, `top -o mem`, showed nothing above a few GB of RSS and no sign of `dasd` at all ^[2]. The signal was on a different screen: swap at 37GB, described by the author as nearly double physical RAM ^[3]. At that point every new allocation is disk I/O, so the moment Playwright asked for a browser context the OS started paging to secure the memory, and 180 seconds was not enough ^[6].

The structural part matters more than the incident. macOS zlib-compresses pages that are not actively used and keeps only the mapping, and that compressed region consumes physical RAM but is not counted in RSS ^[7]. It is visible, but only if you ask for it: `top -l 1 -n 20 -o mem -stats pid,command,mem,cmprs` put `dasd` in the output at 264M MEM and 46G CMPRS, PID 1842 ^[8]. According to the author, `dasd` is the Duet Activity Scheduler, the background task arbitration daemon, and it had accumulated that 46GB over 21 hours of uptime ^[9]. The account attributes the 37GB of swap directly to that compressed pool, though it does not say whether the CMPRS column reports the footprint before compression or the bytes resident after it ^[17].

Threshold design follows from the blind spot. An RSS trigger set at any sane level never fires against 264MB, so the author keys the alert on the `mem` column, which sums CMPRS and the RSS-equivalent figure, with an awk helper normalising T and G suffixes into MB ^[12][13]. That is the transferable part: if your alerting rule reads RSS, its coverage of a compressed leak is zero regardless of how low you set the number.

`dasd` was not alone. A second leaker, a Node.js process the author calls `iii` (agentmemory), managing agent session memory, was growing at roughly 4GB per hour, which at that rate reaches 46GB in about 11 and a half hours ^[11][3]. Manual remediation was five minutes of work, and the author noted the symptom recurring after 21 hours of uptime, which converts the fix into a daily chore of reading `top` and running `sudo killall dasd` ^[10]. The replacement was a script on a 10-minute interval that restarts on threshold crossing and posts to Discord ^[14]. The log line the next morning read reclaimed at 02:32, with swap back at 4.1GB, a drop of about 89 percent from the 37GB peak ^[15][2]. The detection window went from roughly a day to ten minutes, or 144 checks daily ^[4].

Worth verifying before you copy the fix: run the `-stats` variant on your own long-uptime machines and see whether CMPRS is already large, because the 21-hour pattern is one person's observation on one box ^[10]. The revenue framing around this account, 1.2M yen per month, is self-reported and unaudited ^[16]. The monitoring defect is the part that generalises.