• Nayef Ghattas When Go 1.24 was released in early 2025, we were eager to roll it out across our services. • The headline featureâthe new Swiss Tables map implementationâpromised reduced CPU and memory overhead. • Our story begins while the new version was being rolled out internally. • Shortly after deploying it to one of our data-processing services, we noticed an unexpected memory usage increase: We observed the same pattern, a ~20% increase in memory usage, across multiple environments before pausing the rollout. • To confirm our suspicions, we conducted a bisect in the staging environment, which pointed directly to the Go 1.24 upgrade as the culprit. • But hereâs where things got truly puzzling: The increased memory usage wasnât showing up in Go runtime metrics and live heap profiles, which meant that, from the Go runtimeâs perspective, the service wasnât using more memory.
Article Summaries:
- In early 2025, a company rolled out Go 1.24, expecting lower CPU and memory usage thanks to the new Swiss Tables map implementation. After deploying the update to a data‑processing service, they observed a ~20 % rise in memory consumption across multiple environments, yet Go’s runtime metrics and heap profiles showed no change. System metrics, however, indicated higher usage, prompting a staged bisect that pinpointed the Go 1.24 upgrade as the culprit. The team ruled out major changes such as Swiss Tables and spin‑bit mutexes, then traced the issue to a subtle memory allocator regression introduced by a runtime refactor. Working with the Go team, they confirmed the root cause and later leveraged Swiss Tables to reduce memory usage in high‑traffic services.
Sources: