2013-06-26 14 views
5

我有一个运行在Tomcat(Warble)内部的JRuby on Rails应用程序。它使用Java桥接器连接到Progress(OpenEdge)应用程序服务器......当我监视内存时,它只会继续上升。为什么内存永远不会在我的Tomcat JRuby应用程序中发布?

  • Tomcat的7.0
  • JRuby的1.6.7.2(红宝石-1.9.2-P312)
  • JVM 1.7.0.25
  • 滑轨3.2.7
  • jruby的机架1.1.7
  • 莺1.3.6

什么是最好的方式来到这里的问题的底部?我想它可能是未被清理的JRuby对象,或者Java桥或垃圾收集器中没有完成其工作的东西...

即使我让过程运行半个小时,内存不下降...

  • 有没有办法知道哪些对象是活着的?
  • 是否有免费的工具,易于使用,我可以有更多的信息谁正在使用所有的内存?

顺便说一句,我已经配置了Tomcat服务器使用更多的内存,但是这只是延迟堆空间错误...

编辑:什么我实际上看到的是,Tomcat的只是使用它可以最大限度地使用的所有内存(最大内存池)。它永远不会释放它。也许这只是正常的行为......我现在已经将最大值设置为256MB,并且在任务管理器中,内存仅停留在256MB左右。

编辑:

当创建一个堆转储,让月食与Eclipse内存分析器分析这是我得到的报告。我认为,因为该工具可能不会想到整个故事的JRuby这是正常...

问题可疑“org.jruby.RubyClass”,1种

6.458情况下通过“org.apache加载。 catalina.loader.WebappClassLoader @ 0x700ec6988“占据56.969.616(31,78%)字节。

关键词 org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 org.jruby.RubyClass

问题可疑的“org.jruby.internal.runtime.methods 2个

10.597实例。 DefaultMethod“,由”org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988“加载占用22.182.112(12,37%)个字节。

关键词 org.jruby.internal.runtime.methods.DefaultMethod org.apache.catalina.loader。WebappClassLoader @ “org.jruby.RubyModule”,由装 “org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988” 的0x700ec6988

问题可疑3

3.144实例占据21.226.816(11,84 %)个字节。

关键词 org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 org.jruby.RubyModule

问题可疑 “org.jruby.MetaClass”,4个

8.888实例由装“ org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988“占用18.563.784(10,35%)个字节。

关键词 org.jruby.MetaClass org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988

+0

具体问题是什么?你内存不足?什么版本的JRuby?什么版本的Rails?等等。这些中没有一个是“3.7”。 –

+0

具体问题是:错误Java堆空间。 日志中没有更多信息。 –

+0

我会用所有特定版本更新我的问题。 –

回答

1

这闻起来很像内存泄漏。不是一个漂亮的景象。

如果没有很多代码,请首先检查一下,是否关闭了连接和流以及所有具有方法close的对象。如果这是最近出现的问题,请查看上次修改的代码。

我想尝试的其他事情是与some tool代码检查。

也许编写一些测试来加速泄漏(如生成请求),然后可以尝试从应用程序中排除代码,直到找到导致泄漏的区域。

我不建议你检查内存中的对象,因为这是一个缓慢而痛苦的过程。

1

首先:256M堆空间对于Java应用程序来说并不是很多 - 特别是当涉及到一个完整的servlet容器/应用程序服务器和(可能)很多的库时。

Java通常不会将内存交回操作系统 - 一旦分配了内存,它就被认为由JVM拥有。我相信可能会有一些内存管理的实现来回传内存,但我从来没有见过它们。我在生产环境中的典型建议是--Xmx等于-Xms(分配您希望JVM能够立即分配的所有内存)

用尽堆空间是两个(或更多) )条件:a)您的应用程序存在内存泄漏,b)您的应用程序需求分配不足。

JVM的加薪内存分配和监视内存的使用和垃圾收集排除B) - 如果你能肯定地说,你的应用程序有其需要足够的内存,亨特),并找到了病根内存泄漏。你最好使用一个profiler,但是256M的内存很可能会导致内存不足。

相关问题