GC memory fragmentation

Sebastiaan Koppe mail at skoppe.eu
Mon Apr 12 07:03:02 UTC 2021


On Sunday, 11 April 2021 at 09:10:22 UTC, tchaloupka wrote:
> Hi,
> we're using vibe-d (on Linux) for a long running REST API 
> server and have problem with constantly growing memory until 
> system kills it with OOM killer.
>
> [...]
>
> But this is very bad for performance so we've prolonged the 
> interval for example to 30 seconds and now memory still goes up 
> (not that dramatically but still).
>
> [...]
>
> So it wastes a lot of free space which it can't return back to 
> OS for some reason.
>
> Can these numbers be caused by memory fragmentation? There is 
> probably a lot of small allocations (postgresql query, result 
> processing and REST API json serialization).

We have similar problems, we see memory usage alternate between 
plateauing and then slowly growing. Until it hits the configured 
maximum memory for that job and the orchestrator kills it (we run 
multiple instances and have good failover).

I have reduced the problem by refactoring some of our gc usage, 
but the problem still persists.

On side-note, it would also be good if the GC can be aware of the 
max memory it is allotted so that it knows it needs to do more 
aggressive collections when nearing it.


More information about the Digitalmars-d-learn mailing list