Tackling memory leaks… the Go way
We recently discovered two small memory leaks in our worker process, one that affected only the ARM architecture build, and one that affected all builds regardless of the CPU architecture (but only if you use scripting and event-handling). Although both of them were very small and limited in scope, over long periods of time they could lead to the unwanted allocation of a significant part of your system memory.
As many of you know, Go has a pretty nifty garbage-collector, but that doesn’t mean that all memory issues are magically prevented. Programmers still have to be clever with allocations and references.
Long story short, we spent the last week delving in pprof to hunt down, identify, and resolve these two memory leaks, and here’s the result:
As you can see, after our fixes now the worker process uses a stable amount of memory (~120 MB) and CPU (~0.7%) under constant load (~750 Mbps sustained transfer rate from 3 concurrent clients). The chart above was acquired over an observation period of 24 hours under stress-test conditions.
These fixes will be incorporated into version 6.0.22.