High memory usage in vibe.d application

[Anton Fediushin]

On Friday, 29 June 2018 at 11:42:18 UTC, bauss wrote:
> On Friday, 29 June 2018 at 11:24:14 UTC, Anton Fediushin wrote:
>> On Friday, 29 June 2018 at 11:01:41 UTC, Anton Fediushin wrote:
>>> On Friday, 29 June 2018 at 10:21:24 UTC, Radu wrote:
>>>> On Friday, 29 June 2018 at 09:44:27 UTC, Anton Fediushin 
>>>> wrote:
>>>>> Almost forgot, there are two timers which call this 
>>>>> function for two different streams.
>>>>>
>>>>> Value of `metaint` is 16000, which means that only 16KB of 
>>>>> memory are allocated for the `buffer`, then it reads 
>>>>> another byte which contains length of the metadata / 16 and 
>>>>> then it reads the metadata which is 100-200 bytes long.
>>>>>
>>>>> This gives us... 16KiB per one nowPlaying() call. Why 
>>>>> doesn't it free the memory?
>>>>
>>>> Maybe use the 
>>>> https://dlang.org/phobos/std_experimental_allocator_mallocator.html instead of theAllocator as it defaults to GC.
>>>
>>> Thanks, I'll try that.
>>> ...
>>> I will deploy that and see if it changes anything.
>>
>> It did! Memory usage went down to 7MiB yet it still grows 
>> slightly. I'll monitor if it changes in a couple of hours but 
>> it is much better.
>>
>> Thank you a lot, Radu. It turns out that theAllocator is so 
>> tricky.
>
> Again you could do @nogc and see what memory is possibly 
> allocated by the GC and perhaps that way you can see what 
> memory the GC is holding on to.

@nogc tells nothing new, just an error on every single line 
because neither `res.bodyReader.read` nor Mallocator's functions 
are marked as @nogc.

Compiling with dmd's `-vgc` flag shows nothing but the last line.

>
> non-GC memory should be freed right away and those there 
> shouldn't be a leak from that.

Using Mallocator instead of theAllocator improved the situation, 
but it still leaks for some reason. After 2 hours it went from 
7MiB to 18MiB.

I will compile it with profile-gc again and look for the possible 
cause of that, maybe I'll try valgrind too.