A systems experiment has identified a sharp latency risk when Go applications run under memory pressure with swap enabled: bookkeeping data needed by the garbage collector can itself be moved out of physical memory. When the runtime later enters a stop-the-world phase and touches those pages, the resulting storage reads can hold up the entire Go process.
The test placed a Go workload and a mostly idle HTTP server in the same Linux control group, then induced memory pressure. The Go process repeatedly built an in-memory object from a 511 KiB message, producing both a byte buffer and a pointer-rich structure that the garbage collector needed to scan. The host used Linux 6.8 with multigenerational LRU enabled, and the experiment was run against local NVMe storage as well as a network-backed volume.
Most garbage-collection pauses remained very short. The reported median was about 51 microseconds. But the worst pause with runtime metadata swapped to NVMe reached roughly 40 milliseconds, about 800 times the median. Instrumentation using BPF attributed 39 milliseconds of that event to 228 page faults while the program was stopped.
The mechanism differs from ordinary heap scanning. Go retains runtime metadata pages and reuses them across collection cycles. Because the kernel makes eviction decisions according to page activity, infrequently touched bookkeeping pages may become swap candidates. At sweep termination and mark termination, Go stops application execution and reads this metadata. If the relevant pages are absent from RAM, the runtime must wait while the kernel resolves major faults and retrieves them from storage.
That makes the impact process-wide rather than confined to one goroutine. Work that becomes ready during the pause cannot run until the collector releases the program. In the 30-minute test, the runtime entered 312 such stop-the-world phases, and long pauses appeared two or three times around each simulated memory spike.
The experiment also observed slower message construction under pressure. A task that normally took three to five milliseconds rose to 105 milliseconds with NVMe swap and 903 milliseconds with the network volume. The author did not establish the exact source of that slowdown, so it should be treated as an observation rather than a diagnosed runtime defect. Unlike the metadata pause, that cost was localized to the allocating goroutine.
The result does not show that swap is universally unsuitable for Go services. It demonstrates a specific tail-latency failure mode that operators should measure when using swap to absorb memory spikes. Tests with Go 1.26's Green Tea collector produced negligible change in this particular effect, according to the experiment. Workloads with tight response-time objectives may therefore need to monitor major faults and stop-the-world duration, and validate their memory-control configuration under realistic pressure before relying on swap as a safety margin.
