RejectedSoftware Forums

On Mon, 17 Apr 2017 16:22:31 GMT, punkUser wrote:

Hey guys,

I'm having a bit of pain with a production system running out of memory periodically - I suspect some sort of leak or GC issue but it's hard to pin down. Do you guys have recommendations of tools or APIs (vibe fiber aware ideally) to use to keep track of live fibers, allocations or memory usage on the fly?

Despite calling GC.collect/minimize periodically virtual memory in Ubuntu rises to very large values and eventually resident gets large enough that an allocation fails once swap is exhausted.

Thanks in advance!

Unfortunately the GC is quite a pain point. dmd -vgc/dub -b profile-gc helps somewhat to find possible sources, but since it only accumulates allocations and ignores freed/collected memory, the numbers are not really suited to find memory leaks.

For the general fiber/task topic, I started to implement a graphical debugger that can be used to keep track of various forms of resource use, connecting it to the active tasks. It also shows the live fiber scheduling to make it possible to detect synchronization/timing issues.

Unfortunately it is not ready for general consumption and I had to put it on the back burner due to a general time shortage.

I've heard that valgrind can also be somewhat useful in this scenario, but I didn't try to use it with D so far.

On Mon, 24 Apr 2017 14:17:48 GMT, punkUser wrote:

On Sun, 23 Apr 2017 12:07:47 GMT, Sönke Ludwig wrote:

Unfortunately the GC is quite a pain point. dmd -vgc/dub -b profile-gc helps somewhat to find possible sources, but since it only accumulates allocations and ignores freed/collected memory, the numbers are not really suited to find memory leaks.

Yeah I've been keeping an eye out as you guys have been gradually shifting things to not use GC and wondering if I should do the same on some of my hotter code/allocation paths... if there was a good way of getting targeted information about which paths were hurting the most I would probably do that, but as you note it seems hard to understand "why is the GC leaving 50GB of address space sitting around", etc. It's not a giant issue for desktop use cases of course, but obviously with Vibe.d you're often trying to fit things into memory-starved VMs :)

Unfortunately it is not ready for general consumption and I had to put it on the back burner due to a general time shortage.

Ah, too bad, but I'll keep an eye out. In terms of basic high level information/sanity checks like how many fibers are currently alive/running/sleeping/whatever is there any easy way to get that information at runtime for logging purposes?

Thanks for the info!

There is no direct number to log, but setTaskEventCallback can be used to keep track of accumulated numbers, as well as could be used to assign allocations or other resource management operations to fibers. This is also the place where the debugger hooks into.