Hi all
We have a go application that processes large numbers of documents. It
behaves like it has a memory leak, eventually exhausting system ram after a
few hours. I've setup pprof and looked at the various outputs, and that is
adamant that the application is only using some 50MB of ram, yet
If you're using cgo to link with C/C++ code then a memory leak in that API
is the first place to start looking..
On Mon, Dec 13, 2021 at 10:14 AM Gareth Owenson
wrote:
> Hi all
>
> We have a go application that processes large numbers of documents. It
> behaves like it has a memory leak, eventu
> It's a heuristic. The Go developers probably observed that starting a GC
approximately every two minutes was a reasonable trade-off between the
overhead of a GC cycle and memory used.
is there any stat/data on this decision? and what will happen if you make
it 1 minute or 5 minutes, average C
And if you are using a cgo and didn't replace the standard malloc with
jemaloc you are probably suffering from memory fragmentation or whatever
the hell happens.
We had to restart the processors every 1000 iterations because of that.
There was no memory leak according to valgrind. (about 300kb),
