Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High memory usage for serving static files #73

Closed
Demayl opened this issue Jul 31, 2018 · 3 comments
Closed

High memory usage for serving static files #73

Demayl opened this issue Jul 31, 2018 · 3 comments

Comments

@Demayl
Copy link

Demayl commented Jul 31, 2018

This example consumes too much RAM ( without freeing it ) every request and sometimes segfaults.
With MVM_SPESH_DISABLE=1 works fine

ab -c 10 -n 10000 http://127.0.0.1:8888/static/test.txt
#!/usr/bin/env perl6
use v6.c;
use Cro::HTTP::Server;
use Cro::HTTP::Router;
use Cro::HTTP::Request;

my $routes = route {
    get -> 'static', *@parts {
#        cache-control :public, :max-age(60 * 60); # 1 hour cache for static files
        static 'static/', @parts;
    }   
}   

mkdir 'static';
spurt 'static/test.txt', "A" x 1*1024*1024; # 1 MB txt file

my $service = Cro::HTTP::Server.new: :host('0.0.0.0'), :port(8888), :application($routes);

say "Start " ~ $*PROGRAM-NAME;

$service.start();
react whenever signal(SIGINT) { say "GOT KILL INT.....EXIT"; $service.stop; exit }

This is Rakudo version 2018.06-281-g7043559bb built on MoarVM version 2018.06-329-g21ea40f68
implementing Perl 6.c.

@Altai-man
Copy link
Member

It without SPESH it works fine, it looks to me like rakudo bug rather than Cro::HTTP one.
Thanks for somewhat golfing the example.

@jnthn
Copy link
Member

jnthn commented Dec 14, 2018

Even more interestingly, it seems that it doesn't leak with MVM_SPESH_INLINE_DISABLE=1 (which means other spesh optimizations, including JIT, are still on).

jnthn added a commit to MoarVM/MoarVM that referenced this issue Dec 14, 2018
In some cases, we can not have a ->work, but still have frame extras
to free. This could add up to quite a large leak over time in longer
running programs. This was the cause of the leak in, for example,
croservices/cro#73, which now converges on a
maximum amount of memory rather than continuously growing.
@jnthn
Copy link
Member

jnthn commented Dec 14, 2018

Tracked it down with massif, and fixed a leak in MoarVM. With that fix, it hits a maximum and then ceases to grow with further requests (threw 50,000 at it, and it didn't budge beyond the point it reached after the first 10,000).

@jnthn jnthn closed this as completed Dec 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants