Why Doesn't Go 1.3 Release Server Memory Back to the System After a Connection Spike?

Go 1.3 garbage collector not releasing server memory back to system

A server developed to examine memory footprint shows fluctuating RES memory despite expected memory release after a spike in connections. The issue arises due to the Go garbage collector's limitations in releasing heap memory immediately and the inaccessibility of goroutine stack memory to the OS. A system call available in Unix-like systems to release unused heap parts is unavailable on Windows, resulting in potentially larger virtual memory consumption.

Initially, the server starts with a minor memory imprint. During the initial pulse of 10,000 connections, memory usage rises to approximately 60MB (as indicated by the RES size in "top"). When the pulse ends, memory usage decreases. However, the RES size remains elevated at 56MB, while the in-use memory never drops below 60MB.

While the Go garbage collector releases heap memory, it does not immediately return it to the system. This process may take up to seven minutes after the GC sweep. Additionally, memory allocated to goroutine stacks is never released to the OS. This contributes to the persistent high memory consumption observed in the server.

Unfortunately, there is no clear solution to this issue in Go version 1.3. However, the situation is expected to improve in subsequent releases. To mitigate the impact, consider the following measures:

• Force garbage collection periodically using runtime.GC().
• Set a limit on the number of connections the server can accept to prevent excessive memory usage.

The above is the detailed content of Why Doesn't Go 1.3 Release Server Memory Back to the System After a Connection Spike?. For more information, please follow other related articles on the PHP Chinese website!