Get largest heap object at runtime? ...tracking the leak
Andres Clari
andres at steelcode.net
Mon Jan 22 06:48:00 UTC 2018
On Monday, 22 January 2018 at 06:15:24 UTC, Dmitry Olshansky
wrote:
> On Sunday, 21 January 2018 at 17:28:13 UTC, Andres Clari wrote:
>> Hi, is there any way to get from the GC all allocated objects,
>> so I can see their size and find where I'm leaking memory? Or
>> perhaps a good tool to help with this issue...
>>
>> I tried building my program with "profile-gc" but I got an
>> invalid MemoryOperationError with no stack trace... so no luck
>> using that. And the leak is only obvious when running in
>> production, where after 6 hours I've seen 1.5Gb of memory
>> usage.
>
>
> Are you by chance using vibe.d?
> In versions 0.8.x I observe a huge memory leak. Might be your
> problem.
>
>>
>> Right now, I'm able to extend the life of my program by
>> injecting calls to:
>> GC.collect
>> GCminimize
>>
>> Within an event that happens every 5 seconds, which I estimate
>> will give me about a week before the program's memory is again
>> at +1.5Gb.
Yeah.
Although after doing some manual tracking and isolation of the
suspect routines, I found that using "std.concurrency.spawn" to
run a http post request with the "requests" library was the
leaking suspect.
I'm triggering some 15 requests every 5 seconds in production, so
it's obvious there, but querying "GC.usedSize" I was able to
observe the same on my dev environment.
After removing the "spawn" call, and wrapping up the post code
inside a "runTask", it seems to work properly now, and so far I
have a consistently small memory size in production.
Not sure why "spawn" would leak like that tho. I would assume
that once the thread exits, it would get destroyed and it's
resources reclaimed, specially when I have calls to "GC.collect
and GC.minimize".
More information about the Digitalmars-d-learn
mailing list