5

I have a JRuby on Rails application which is running inside Tomcat (Warble). It uses a Java bridge to connect to a Progress(OpenEdge) application server... When I monitor the memory, it only keeps going up.

  • Tomcat 7.0
  • JRuby 1.6.7.2 (Ruby-1.9.2-p312)
  • JVM 1.7.0.25
  • Rails 3.2.7
  • jruby-rack 1.1.7
  • warbler 1.3.6

What's the best way to get to the bottom of the problem here? I guess it could either be JRuby objects that aren't cleaned up, or something in the Java bridge or the Garbage collector that doesn't do its job...

Even if I let the process run for half an hour, the memory doesn't go down...

  • Is there a way to know which Objects are alive?
  • Are there free tools which are easy to use by which I can have more information on who is using all the memory?

By the way, I already have configured the Tomcat server to use more memory, but that's just delaying a heap space error...

EDIT: What I'm actually seeing is that Tomcat just uses all the memory that it can maximum use (Maximum memory pool). And it never releases it. Maybe it's just normal behavior... I've now set maximum to 256MB for example and in the Task Manager, the memory just stays around 256MB.

EDIT:

When creating a heap dump and letting eclipse analyze it with the Eclipse Memory Analyzer this is the report I'm getting. I think it's normal since the tool probably doesn't expect the whole JRuby story...

Problem Suspect 1

6.458 instances of "org.jruby.RubyClass", loaded by "org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988" occupy 56.969.616 (31,78%) bytes.

Keywords org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 org.jruby.RubyClass

Problem Suspect 2

10.597 instances of "org.jruby.internal.runtime.methods.DefaultMethod", loaded by "org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988" occupy 22.182.112 (12,37%) bytes.

Keywords org.jruby.internal.runtime.methods.DefaultMethod org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988

Problem Suspect 3

3.144 instances of "org.jruby.RubyModule", loaded by "org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988" occupy 21.226.816 (11,84%) bytes.

Keywords org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 org.jruby.RubyModule

Problem Suspect 4

8.888 instances of "org.jruby.MetaClass", loaded by "org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988" occupy 18.563.784 (10,35%) bytes.

Keywords org.jruby.MetaClass org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988

Lieven Cardoen
  • 25,140
  • 52
  • 153
  • 244
  • What's the specific problem? Do you run out of memory? What version of JRuby? What version of Rails? Etc. There isn't a "3.7" of any of those. – Dave Newton Jun 26 '13 at 18:41
  • The specific problem was: ERROR Java Heap Space. There was no more info in the logs. – Lieven Cardoen Jun 27 '13 at 06:29
  • I'll update my question with all the specific version. – Lieven Cardoen Jun 27 '13 at 06:30
  • I have gotten information on memory/cpu/threads from Java VisualVM. I'm still curious to know if the Problem Suspects from Eclipse Memory Analyzer are really a problem. – Lieven Cardoen Jun 27 '13 at 10:24
  • 1
    @LievenCardoen, Did you check, which part of generational heap space (Eden, Tenured or PermGen ) is increasing and not released ? If its PermGen, then there is nothing much you can do. – Santosh Jul 05 '13 at 03:30
  • @Santosh It's indeed the PermGen and I think you're right that there's not much to do about it. Thx. – Lieven Cardoen Aug 01 '13 at 15:19

2 Answers2

2

First of all: 256M Heap Space is not a lot for Java applications - especially as a full blown servlet container / app server is involved and (likely) lots of libraries.

Java typically does not hand memory back to the operating system - once allocated the memory is considered to be owned by the JVM. I believe there might be some implementations of memory management that hand back memory, but I've never seen them. My typical recommendation in production environments is to have -Xmx equal -Xms anyway (allocate all the memory you want the JVM to be able to allocate immediately)

Running out of Heap Space is a signal for one of two (or more) conditions: a) You have an application with a memory leak, b) you are not allocating enough for the application demand.

Raise memory allocation for your JVM and monitor the memory use and garbage collection to rule out b) - if you can safely say that your application has enough memory for its needs, hunt for a) and locate the root cause for the memory leak. You'll best use a profiler for that, but with 256M of memory, there's a great chance that you just have not enough memory.

Olaf Kock
  • 46,930
  • 8
  • 59
  • 90
1

This smells a lot like memory leak. Not a pretty sight.

If there is not a lot of code, first check by eye, that you are closing connections and streams and all objects that have method close. If this is problem showed up recently, take a look at the code last modified.

Other thing i would try is a code inspection with some tool.

Maybe write some tests to speed up the leak (like generating requests), you can then try excluding code from application, until you find area that is causing leak.

I don't recommend you inspecting objects in memory since it is a slow and painful process.

Community
  • 1
  • 1
terafor
  • 1,620
  • 21
  • 28