Find memory leak in 1.9 app

[Julien Schmurfy]

Hello,
I am in charge of a ruby server at my work for nearly 2 years now, it
works pretty well but as our users base grows we start seeing a clear
and constant increase in memory usage over the day so here I come !

I am pretty sure it's a references leak and as a result that it is in
our code and not a leak in the interpreter but my problem is the
inexistence of any real solution to debug memory usage on 1.9 (I hope
someone could prove me wrong on this), the more successful attempt I
made was to dump all the Object count by iterating over ObjectSpace in
ruby code, while it works... sometimes, it is really inefficient and I
did not manage to get any result with this method.

My problem is that I use Fiber so I cannot really try on 1.8.x, I still
tried to run it on 1.8.7 with the fiber18 emulation but when I do the
memory stay stable...

We resorted on running the server on 1.8.7 for now (after backporting
any 1.9 specific code) but that is really an horrible long term solution
:/

I am keeping a close look on rubinius which could help me but until then
does anyone have any option for me ? I don't need something really
complicated, if only I got a C extension to dump the objects that would
be a nice start but i did not even found that running with 1.9.

Sadly it looks like 1.8 is still the preferred version for so many
people (nearly all the tools i saw were started are still developed on
1.8).

Any help/pointers would be much appreciated.

 

[Roger Pack]

valgrind might help, jruby has some "high powered" profile methods, and
does http://timetobleed.com/memprof-a-ruby-level-memory-profiler/ work
with 1.9?

 

[Julien Schmurfy]

Hi,
Thanks for you answer,
I already tried memprof but while it looks great it has the same comment
as all the other tools:
"Ruby 1.9 support coming soon.".
As for jruby one of the problems is that it is another virtual machine
and I may experience the same differences that i do with 1.8.7 (and it
was not 1.9 compatible last time I checked so no Fibers either) but the
main problem is we use eventmachine and while it is nice that the gem
itself implements three versions (native, ruby, jjruby) they are all
differents so... useless.
Last time i tried to run my code under jruby there was so many problems
I just gave up.

I may give valgrind a try, do you have any experience with it to find
ruby memory leaks ?

 

[Charles Oliver Nutter]

As for jruby one of the problems is that it is another virtual machine
and I may experience the same differences that i do with 1.8.7 (and it
was not 1.9 compatible last time I checked so no Fibers either) but the
main problem is we use eventmachine and while it is nice that the gem
itself implements three versions (native, ruby, jjruby) they are all
differents so... useless.
Last time i tried to run my code under jruby there was so many problems
I just gave up.

If it was simply 1.9 support holding you back with JRuby, you may want
to try JRuby 1.6.0.RC1, which shipped greatly-improved Ruby 1.9.2
compatibility. Not perfect yet, I'm sure, but far better than it used
to be.

But yes, if your leak is likely in an MRI-specific library, like EM,
profiling on JRuby probably won't tell you much (and JRuby might not
exhibit the problem at all). I sympathize.

- Charlie

 

[Julien Schmurfy]

Charles Nutter wrote in post #975365:

If it was simply 1.9 support holding you back with JRuby, you may want
to try JRuby 1.6.0.RC1, which shipped greatly-improved Ruby 1.9.2
compatibility. Not perfect yet, I'm sure, but far better than it used
to be.

But yes, if your leak is likely in an MRI-specific library, like EM,
profiling on JRuby probably won't tell you much (and JRuby might not
exhibit the problem at all). I sympathize.

I never said I suspected eventmachine or any mri native library to be
the cause of the leak, in fact I even doubt it, I just said that the
jruby version of eventmachine was not on par with the mri native one:
some methods are not implemented in the jruby version which makes the
APIs incompatible and would require a rewrite of some part of the
application in order to run (if a substitute exists for these missing
methods).

Thanks for the information on jruby 1.6 I may give it another try in
last resort.

 

[Charles Oliver Nutter]

I never said I suspected eventmachine or any mri native library to be
the cause of the leak, in fact I even doubt it, I just said that the
jruby version of eventmachine was not on par with the mri native one:
some methods are not implemented in the jruby version which makes the
APIs incompatible and would require a rewrite of some part of the
application in order to run (if a substitute exists for these missing
methods).

Understood. The maintainers of the JRuby EM would probably love to
have help implementing anything that's missing, btw

- Charlie