Why Doesn't My Go 1.3 Server Release Memory Back to the OS?

Go 1.3 Garbage Collector Retention of Server Memory

Understanding the Problem

A TCP server handling connections with irregular traffic is using significant amounts of system memory that is not being released back to the operating system. This behavior becomes problematic when running multiple servers on the same machine, as memory resources can be depleted over time.

Background

Go's garbage collector (GC) frees unused heap memory, but it doesn't always shrink the process's virtual address space. On Windows platforms, this is not possible. Even on Unix-based systems, Go uses a system call to inform the OS that unused heap memory can be reclaimed, but this takes time (up to 7 minutes).

Analysis

Based on information gathered from Go community forums, the issue may be related to the following factors:

• Go does not release all memory to the OS: Go only releases heap variables; goroutine stacks are not released.
• Delayed Memory Release: Memory may not be returned to the OS immediately after being marked free by the GC. An OS sweep is also required, which can take up to 7 minutes.
• Overreported Memory Usage: Not all allocated memory is "real" memory. Some may be used by the runtime but not the program, leaving the OS to handle.

Potential Solutions

• Explicit Memory Release: Force garbage collection with runtime.GC() and explicitly release memory to the OS using runtime.FreeOSMemory.

Limitations

• runtime.GC() should be used sparingly, as it can impact performance.
• runtime.FreeOSMemory only works if the GC has run.
• Goroutine stack memory will not be released.

Acknowledgments

• Dmitri Vyukov (Go developer) provided key insights on the issue.

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