Google Compute Engine’s e2-micro instances are a staple of the GCP Free Tier, offering 2 vCPUs and roughly 1 GB of RAM (969 MiB usable). They are ideal for lightweight bastions, cron runners, and small test beds. However, if you run memory-sensitive workloads—such as Go builds, package extractions, or continuous process forks—you may have experienced intermittent, baffling SSH connection timeouts and unresponsive terminals.

The root cause is rarely your application alone. By default, GCE provisions a suite of Google guest daemons that consume a disproportionate share of resident memory on small VMs, creating an environment primed for SSH exhaustion.

For engineers running lean environments on WSL 2, every megabyte of RAM and every CPU cycle counts. Many developers are unaware of the significant “performance tax” imposed by kernel-level mitigations for vulnerabilities like Spectre and Meltdown.

In a recent set of benchmarks on a Go-based backend project, disabling these mitigations resulted in a 31.7% reduction in wall-clock compilation time. Here is how you can audit your system and decide if the trade-off is right for your workflow.

There was a great discussion a year ago about how fast gnu’s version of “yes” is. If you’re unfamiliar, yes outputs y indefinitely.

yes |head -5
y
y
y
y
y

The key takeaway was that write is expensive and writing page-aligned buffers is much faster. The is true across languages, so let’s see how to do it properly in go.

If you’re shocked or impressed by the results, let’s see you do it in your language – post your results in the comments.