High memory usage in vibe.d application

[Daniel Kozak]

Have you try use VibeManualMemoryManagement

https://github.com/TechEmpower/FrameworkBenchmarks/blob/3b24d0a21463edc536b30e2cea647fd425915401/frameworks/D/vibed/dub.json#L22


On Fri, Jun 29, 2018 at 3:20 PM Anton Fediushin via Digitalmars-d-learn <
digitalmars-d-learn at puremagic.com> wrote:

> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20180629/62a88834/attachment.html>