The load average had already peaked: reading 11.08 / 38.69 / 23.59 in the right order

A four-core Linux box came close to falling over under a load average of 38.7, and by the time that number was read the worst of it was already over ^[1][2]. The ordering of the three load figures and two counters from /proc/pressure established that before any application log was opened, which is the transferable part of the story ^[3][4]. The reading was 11.08, 38.69, 23.59: one minute, five minutes, fifteen minutes ^[2]. A crisis still climbing puts its largest figure in the one-minute slot; this set was descending from a peak that sat in the five-minute window, so the event had already happened and was decaying while the operator was still reading it ^[3]. Then /proc/pressure, the kernel's stall accounting for CPU, memory and IO: memory full at 10 percent, meaning processes genuinely stopped waiting on page reclaim, and IO some at 45 percent ^[4]. According to the author's writeup, that pairing is memory pressure that has turned into an IO storm ^[5]. The link back to 38.7 is D state. Processes parked in uninterruptible IO waits count into the load average exactly as if they were running, and a runc process and a node healthcheck were caught in that state ^[6]. On four cores, 38.69 works out to 9.7 tasks per core ^[1], but the composition was modest real work plus a crowd of processes waiting in the kernel rather than thirty-eight cores' worth of computation ^[7]. Elimination was quick. No OOM kills in the kernel log ^[8]; docker stats showed every container under 500 MB with single-digit CPU ^[9]; disk at 65 percent ^[10]. A process list sorted by memory and grouped gave llama.cpp at 3.9 GB, seven Java services at 2.3 GB and k3s at 1.1 GB, all steady state ^[11]. That is 7.3 GB combined, the same figure that 59 vscode-server processes were holding on their own ^[12][2]. Fifty-nine is a count, not a structure, and the decisive hour went into the process tree, PPID by PPID ^[13]. Remote-SSH runs one server per client version, parented to init rather than to an SSH session, so no session teardown kills it, and that server hosts every window the client opens with one extension host per window ^[14]. A server started on August 9th was hosting two: the live window, and an old window from August 14th whose extension host had grown to seventeen processes and 3.2 GB, containing the Claude session that hung the night before plus four more claude processes born of retries between 2:04 and 2:11 a.m., with the old ones never exiting ^[15]. A second server tree of thirteen processes, another device's window from 8:26 that morning, completed the census ^[16]. Because the live window shared the August 9th server, the kill list could only be the old window's extension-host tree and the other device's entire tree ^[17], roughly thirty of the fifty-nine processes ^[3]. Accumulation ran from 15:17 on the 14th, when the old window connected and the stalled session began its hour-long hang, to 8:26 the next morning ^[18]. There was no swap, memory crept past 85 percent, and alerts set at 80 and 90 percent are spike detectors that arrive with hours of momentum behind them on growth that gradual ^[19]. Six versions of the server binary had also piled up in ~/.vscode-server, one per client upgrade, at 3.8 GB ^[20]. Ignition was 10:59 to 11:09: a new connection and a reconnect brought up two fresh extension hosts and their language servers, CPU- and IO-heavy, on a box whose page cache was already being squeezed ^[21]. The five-minute peak of 38.7 covers exactly those eleven minutes ^[22]. From the 15:17 connection to 11:09 is 19 hours and 52 minutes ^[4]. The author frames the postmortem around four layers that each had a job and each failed for a specific reason ^[23].