5

Tomcat (Warble) 内で実行されている JRuby on Rails アプリケーションがあります。Java ブリッジを使用して Progress(OpenEdge) アプリケーション サーバーに接続します... メモリを監視すると、メモリが増え続けます。

  • トムキャット 7.0
  • JRuby 1.6.7.2 (Ruby-1.9.2-p312)
  • JVM 1.7.0.25
  • レール 3.2.7
  • jruby ラック 1.1.7
  • ウグイス1.3.6

ここで問題の根底に到達するための最良の方法は何ですか? クリーンアップされていないJRubyオブジェクトか、Javaブリッジまたはガベージコレクターの何かがその仕事をしていない可能性があると思います...

プロセスを30分実行しても、メモリは減りません...

  • どのオブジェクトが生きているかを知る方法はありますか?
  • 誰がすべてのメモリを使用しているかについてより多くの情報を得ることができる、使いやすい無料のツールはありますか?

ところで、Tomcat サーバーがより多くのメモリを使用するように構成済みですが、それは単にヒープ スペース エラーを遅らせているだけです...

編集：私が実際に見ているのは、Tomcatが最大使用できるすべてのメモリ（最大メモリプール）を使用していることです。そしてそれは決してそれを解放しません。多分それはただの通常の動作です...たとえば、最大を256MBに設定しましたが、タスクマネージャーでは、メモリは約256MBのままです。

編集：

ヒープ ダンプを作成し、Eclipse に Eclipse メモリ アナライザーで分析させると、このようなレポートが得られます。ツールはおそらくJRubyのストーリー全体を期待していないので、それは正常だと思います...

問題の容疑者 1

「org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988」によってロードされた「org.jruby.RubyClass」の 6.458 インスタンスは、56.969.616 (31,78%) バイトを占有します。

キーワード org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 org.jruby.RubyClass

問題の容疑者 2

「org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988」によってロードされた「org.jruby.internal.runtime.methods.DefaultMethod」の 10.597 インスタンスは、22.182.112 (12,37%) バイトを占有します。

キーワード org.jruby.internal.runtime.methods.DefaultMethod org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988

問題の容疑者 3

「org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988」によってロードされた「org.jruby.RubyModule」の 3.144 インスタンスは、21.226.816 (11,84%) バイトを占有します。

キーワード org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988 org.jruby.RubyModule

問題の容疑者 4

「org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988」によってロードされた「org.jruby.MetaClass」の 8.888 インスタンスは、18.563.784 (10,35%) バイトを占有します。

キーワード org.jruby.MetaClass org.apache.catalina.loader.WebappClassLoader @ 0x700ec6988

4

2 に答える 2

2

まず第一に: 256M のヒープ領域は、Java アプリケーションにとっては多くありません。特に、本格的なサーブレット コンテナー/アプリ サーバーが関与し、(おそらく) 多数のライブラリが含まれているためです。

Java は通常、オペレーティング システムにメモリを返しません。割り当てられたメモリは、JVM によって所有されていると見なされます。メモリを戻すメモリ管理の実装がいくつかあると思いますが、見たことはありません。実稼働環境での私の典型的な推奨事項は、-Xmx を -Xms と等しくすることです (JVM がすぐに割り当てられるようにするすべてのメモリを割り当てます)。

ヒープ領域の不足は、次の 2 つ (またはそれ以上) の状態のいずれかを示しています。

JVM のメモリ割り当てを増やし、メモリ使用とガベージ コレクションを監視して b) を除外します。アプリケーションに必要な十分なメモリがあると安全に判断できる場合は、a) を探して、メモリ リークの根本原因を突き止めます。そのためにはプロファイラーを使用するのが最適ですが、256M のメモリを使用すると、十分なメモリがない可能性が高くなります。

于 2013-07-05T12:03:47.627 に答える
1

これは、メモリリークのようなにおいがします。きれいな光景ではありません。

コードが多くない場合は、接続とストリーム、および method を持つすべてのオブジェクトを閉じていることをまず目で確認してくださいclose。これが最近発生した問題である場合は、最後に変更されたコードを見てください。

私が試みる他のことは、いくつかのツールを使用したコード検査です。

リークを高速化するためのテスト (リクエストの生成など) を作成すると、リークの原因となっている領域が見つかるまで、アプリケーションからコードを除外してみることができます。

メモリ内のオブジェクトを検査することは遅くて面倒なプロセスであるため、お勧めしません。

于 2013-07-01T12:25:30.877 に答える