- PR -

TOMCATとメモリの関係。。。

«前のページへ 1|2
投稿者投稿内容
まりり
ぬし
会議室デビュー日: 2001/12/05
投稿数: 329
投稿日時: 2003-09-12 11:32
引用:

悪夢を統べるものさん

レスありがとうございます。
SUNのドキュメントを読み返したところ、
System.gc()は呼ぶべきでないということがわかりました。
さらに System.gc() を禁止するオプションもあるそうで。。。

JVMの内部を知るにはやはり商用オプティマイザが必要かな・・・

なんとなくまだわかっていないように見受けられます・・・
オプティマイザがあったってJVMの中の動きはわからないと思いますが。

結局のところ、VMがどれだけのメモリを食っているかなんて気にしたって
仕方ないですし、確保しているメモリを制御できると思うのが間違いです。
コントロールできるのはインスタンスの生き死にだけ。
気にすべきはいらないインスタンスをちゃんと片付けているか、です。

元の質問のContextのリロードで使用メモリが減らない話だって、VMが
必要なタイミングで片付けてくれます。
片付かない（メモリ使用量が純粋に増えていくだけ）のであれば、アプリで
適切にインスタンスを破棄していないので、そちら側から原因を探りましょう。
raystar
ぬし
会議室デビュー日: 2003/01/16
投稿数: 251
お住まい・勤務地: Tokyo/Japan
投稿日時: 2003-09-13 01:50
引用:

元の質問のContextのリロードで使用メモリが減らない話だって、VMが
必要なタイミングで片付けてくれます。
片付かない（メモリ使用量が純粋に増えていくだけ）のであれば、アプリで
適切にインスタンスを破棄していないので、そちら側から原因を探りましょう。

ｈｍｍ。。。

サーブレット、JavaBeanなどのオブジェクトは
Eden領域に入るような短命オブジェクトでは
ないため、このような問題が起きているのではと思っておりますが。



[ メッセージ編集済み 編集者: raystar 編集日時 2003-09-13 02:23 ]
raystar
ぬし
会議室デビュー日: 2003/01/16
投稿数: 251
お住まい・勤務地: Tokyo/Japan
投稿日時: 2003-09-13 02:10
引用:

目的は、OutOfMemoryError が出ることを抑止したいのでしょうか、
それとも、パフォーマンスチューニング(速度やメモリ消費量)でしょうか。
私は Linux や Tomcat は良く知らないのですが、
現在の Java VM の多くは、OS から一度確保してしまったメモリを手放すことは
あまり積極的にしないか、あるいは全然しないと思います。

単に、アプリケーションや Tomcat や VM のメモリリークかどうかを心配されていて
(さらに将来 OutOfMemoryError が出ることを恐れられている)のならば、
-XmsM や -Xmx の値をかなり小さ目にして、
それで OutOfMemoryError が出るかを調べられれば良いです。
出なければ、パフォーマンスチューニングの問題だけになります
(少なくともメモリリークはなく、ロジックの問題はない)。
さらには java の起動時オプションで
-verbose:gc
を付けてその変化を見ると安心できます。


unibonさん、こんにちは。
第一の目的はOutOfMemoryを抑制することです（頻繁にはおこりませんが）
その後の目的としてメモリ使用量の抑制です。
インスタンスを生成して使ってしまうメモリは仕方ありませんが、
無駄に増えて解放せず遊んでいる領域（例えばリロード後の元インスタンスなど？）
をできる限り落として行きたいと思っています。

-verbose:gcオプションをつけて、
テストサーバで色々実験してみようかと思います。
raystar
ぬし
会議室デビュー日: 2003/01/16
投稿数: 251
お住まい・勤務地: Tokyo/Japan
投稿日時: 2003-09-13 02:21
引用:

Ken-Labさんの書き込み (2003-09-12 08:51) より:

アプリケーションの入れ替えを何回も行うことで飛躍的にメモリー使用量が増えて
いるのではないでしょうか？？

# 追記です。
# 恐らくトランスレータおよびコンパイラを使った後メモリー使用量が減少しないのは
# 2度目以降の処理速度を上げるために、これらがメモリーに常駐しているのでは？と
# 考えることもできます。よって、Tomcat+JVMが本当に必要とするメモリーサイズは、
# これらの操作後の値と解釈することができるかもしれません。


レスありがとうございます。

そのとおりでございます。
同じ経験をしている人ってやっぱりいますよね。。

Contextリロードを続けることによって、
メモリが波状するということですよね。。

TOMCATがJSPをコンパイルするために、javacを呼ぶjavaインスタンスが常駐しているとも
考えることができるかな・・・（かなりあてずっぽですが）
未記入
大ベテラン
会議室デビュー日: 2003/06/28
投稿数: 219
投稿日時: 2003-09-13 08:38
引用:

TOMCATがJSPをコンパイルするために、javacを呼ぶjavaインスタンスが常駐しているとも
考えることができるかな・・・（かなりあてずっぽですが）

コンパイラが常駐するというよりも、こちらの考えのほうが自然でしょうね。
Tomcat自身が使用するメモリーサイズについてはどうにもならないでしょうから、それは
置いておいて・・・気にかけているのはコンテナに載せたアプリのインスタンスリーク（？）
によるものかどうかという点でしょうか。
既に実施されているかもしれませんが、シングルトンパターンが約束される簡単な
プログラムを載せて、その時のメモリー変化量と実際のアプリを載せた場合の変化量を
比較してみるのはどうでしょう？恐らくどちらもアクセスがある度に増加していくと
思いますが、実際のアプリであまりにもドラスティックに変化するようであれば、
デバッグが必要になるかもしれないですね。
# 余談ですが、そもそもtop表示を過信して良いものか、という検証もあわせて必要かも。
#（注）「インスタンスリーク」は、この問題をイメージした造語でございます。
# 一般的には通用しないことをお断りしておきます。

[ メッセージ編集済み 編集者: Ken-Lab 編集日時 2003-09-13 21:26 ]
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）