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

Using Proc::Async with tap leads to memory leak #5974

Open
p6rt opened this issue Jan 3, 2017 · 11 comments
Open

Using Proc::Async with tap leads to memory leak #5974

p6rt opened this issue Jan 3, 2017 · 11 comments

Comments

@p6rt
Copy link

@p6rt p6rt commented Jan 3, 2017

Migrated from rt.perl.org#130494 (status was 'open')

Searchable as RT130494$

@p6rt
Copy link
Author

@p6rt p6rt commented Jan 3, 2017

From @ronaldxs

The example below is believed to be a simplification of memory leak
Issue #​1104 [1] for the htmlify.p6 program of
http://github.com/perl6/doc.

The program just echoes numbered lines through the UNIX 'cat' program
and uses Perl 6 multiprocessing mechanisms to read back the echoed
lines. It leaks 1 Gig of memory on my system fairly quickly.

This issue occurs with Perl 6 doc generation of pod code blocks. At
Pod​::To​::HTML line 300 [2] a callback mechanism is used which htmlify.p6
uses to format some pod code blocks using Node.js. The code below does
a simplified simulation of those callbacks.

my $proc = Proc​::Async.new('/usr/bin/env', 'cat', :r, :w);
my $proc-supply = $proc.stdout.lines;
my $proc-prom = $proc.start;

my $last;
loop (my $i = 0; $i < 10_000; $i++) {

  say $i if $i %% 1_000;

  my $p = Promise.new;

  my $tap = $proc-supply.tap( -> $cat-echo {
  $p.keep($cat-echo);
  $tap.close();
  } );

  $proc.say('line ' ~ $i); # $tmp_fname);
  await $p;
  $last = $p.result;
}

say $last;

 

Links​:


[1] Raku/doc#1104
[2]
https://github.com/perl6/Pod-To-HTML/blob/master/lib/Pod/To/HTML.pm#L300

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Jan 3, 2017

From @zoffixznet

On Tue, 03 Jan 2017 10​:33​:31 -0800, ronaldxs wrote​:

Links​:
------
[1] Raku/doc#1104
[2]
https://github.com/perl6/Pod-To-HTML/blob/master/lib/Pod/To/HTML.pm#L300

Confirmed on Rakudo version 2016.12-52-g9eed276 built on MoarVM version 2016.12-6-g65acd55 on running on Linux. Memory keeps slowly increasing; got up to 1.1GB by 48000 iterations.

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Jan 3, 2017

The RT System itself - Status changed from 'new' to 'open'

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Jan 10, 2017

From @jnthn

On Tue, 03 Jan 2017 12​:36​:10 -0800, cpan@​zoffix.com wrote​:

On Tue, 03 Jan 2017 10​:33​:31 -0800, ronaldxs wrote​:

Links​:
------
[1] Raku/doc#1104
[2]
https://github.com/perl6/Pod-To-
HTML/blob/master/lib/Pod/To/HTML.pm#L300

Confirmed on Rakudo version 2016.12-52-g9eed276 built on MoarVM
version 2016.12-6-g65acd55 on running on Linux. Memory keeps slowly
increasing; got up to 1.1GB by 48000 iterations.

Worth retrying on HEAD, which has a number of fixes and improvements resulting from analyzing this issue.

/jnthn

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Jan 10, 2017

From @ronaldxs

Worth retrying on HEAD, which has a number of fixes and improvements
resulting from analyzing this issue.

/jnthn

Both code sample and htmlify.p6 still leak for me. Sorry.

ron@​ron-laptop​:~/.rakudobrew/moar-nom$ perl6 -v
This is Rakudo version 2016.12-272-g9a11eac built on MoarVM version 2016.12-100-gf9e14e9
implementing Perl 6.c.

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Jan 11, 2017

From @ronaldxs

Just to try to quantify for future reference or anyone interested ...

my $proc-prom = $proc.start;

my $last;
loop (my $i = 0; $i < 10_000; $i++) {
  if ($i == 2 || $i == 10 || $i %% 1_000) {
  say "pmap after $i iterations";
  my $pmap = run('pmap', $*PID, :out);
  say | $pmap.out.lines.grep(/^\s*total/);
  }

  my $p = Promise.new;

  my $tap = $proc-supply.tap( -> $cat-echo {
  $p.keep($cat-echo);
  $tap.close();
  } );

  $proc.say('line ' ~ $i); # $tmp_fname);
  await $p;
  $last = $p.result;
}

say $last;

/*** prints ***/

pmap after 0 iterations
total 94952K
pmap after 2 iterations
total 141824K
pmap after 10 iterations
total 241568K
pmap after 1000 iterations
total 475952K
pmap after 2000 iterations
total 578520K
pmap after 3000 iterations
total 684888K
pmap after 4000 iterations
total 797292K
pmap after 5000 iterations
total 899428K
pmap after 6000 iterations
total 1012452K
pmap after 7000 iterations
total 1114832K
pmap after 8000 iterations
total 1229764K
pmap after 9000 iterations
total 1333620K
line 9999

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Jan 25, 2017

From @jnthn

On Tue, 10 Jan 2017 14​:30​:27 -0800, ronaldxs wrote​:

Both code sample and htmlify.p6 still leak for me. Sorry.

Yes, I wasn't entirely clear - there was more than one issue, and so fixing the first couple of issues only improved things rather than fully resolved them. I just bumped MOAR_REVISION again to get another set of fixes, which almost completely address the leakage. There is a tiny leak remaining that I'm aware of (about 8 bytes per write), so I'll leave this open for now, but by my measurements it seems to converge around 1000 iterations and leak very little beyond then. (This kind of initial growth and convergence is normal behavior.)

/jnthn

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Jan 25, 2017

From @ronaldxs

Hi. I now have 2 ubuntu/Rakudo computers, a desktop and an old laptop, and after upgrading both to a current Rakudo, Rakudo version 2017.01-52-g42a1eff built on MoarVM, I see differing results.

On the older laptop that showed the problem before I see fairly identical behavior to before the fix. Memory goes from 100k to 1.3Gig at 10_000 iterations and when I step to 18_000 iterations I get 2.3Gig.

On the new ubuntu/rakudo running on an i7 under a Windows 10 hypervisor I get the behavior you describe of going to 1Gig before 2000 iterations and then staying stable up through 18_000 iterations.

So AFAIK both machines are running rakudo from today / this afternoon ET, and both are running ubuntu 14.04. The computer that gets the results you describe is an intel i7 with 16Gig Ram running Windows 10 and running ubuntu under a hypervisor. The hypervisor has some say in memory management is configured for dynamic memory allocation. The computer that still seems to show a memory leak is a dual pentium laptop with 2Gig of Ram. Both systems have swap. "make html" still runs out of memory in the doc repository on the notebook.

If you want me to run any test or diagnostics on either computer please let me know.

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Feb 19, 2017

From @ronaldxs

One other difference between the laptop and desktop computers that had differing memory leak behavior is that the laptop was running 32 bit Ubuntu and the desktop 64 bit Ubuntu. I retested after noticing the following release note for 2017-02​:

Fixed overflow during full GC collection on 32-bit systems

The fix made me aware of the possibility that 32 bit and 64 bit systems might have different memory management issues. Running with rakudo 2017-02 (slightly different versions) 64 bit shows the behavior I described on my last note of stabilizing at 1 Gig. With 2017-02 32 bit now stabilizes around 460k. I sort of understand that doubling the size of a memory word may double the amount of memory but wonder if there may not be some further room for optimization on 64 bit given 32 bit can get by with half the memory.

There is still some slow leakage of a few (~3%) over ten thousand iterations. Also htmlify.p6 can now run on my 2Gig laptop without running out of memory. At this point this leak seams to be at least lower priority and possibly fixed.

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Feb 20, 2017

From @ronaldxs

jnthn mentioned on irc awareness of at least one more leak (presumably) related to this ticket and so ticket waits on news of fixing further leak(s).

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Mar 31, 2018

From @dogbert17

On Mon, 20 Feb 2017 06​:39​:32 -0800, ronaldxs wrote​:

jnthn mentioned on irc awareness of at least one more leak
(presumably) related to this ticket and so ticket waits on news of
fixing further leak(s).

Running the example above one a 32-bit Linux VM I get​:

This Rakudo version is 2018.03.136.g.768.cf.9.f.29 built on MoarVM version 2018.03.58.g.0.aaea.3.c.4.f,
running on ubuntu (14.04.3.LTS.Trusty.Tahr) / linux (3.19.0.32.generic)

pmap after 0 iterations
total 119328K
pmap after 2 iterations
total 127940K
pmap after 10 iterations
total 129200K
pmap after 1000 iterations
total 168160K
pmap after 2000 iterations
total 174984K
pmap after 3000 iterations
total 182564K
pmap after 4000 iterations
total 183984K
pmap after 5000 iterations
total 183984K
pmap after 6000 iterations
total 186788K
pmap after 7000 iterations
total 189404K
pmap after 8000 iterations
total 199460K
pmap after 9000 iterations
total 199460K
line 9999

So it looks as if things have improved considerably

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant