- PR -

WAS6.1における実メモリーの使い方

1
投稿者投稿内容
Aray
会議室デビュー日: 2007/08/28
投稿数: 3
投稿日時: 2007-08-28 13:20
WAS6.1による共用インフラの運用管理をしております。
今回、ぐちゃぐちゃなJVM＆EARの構成を見直すことになり、その構成を限られたリソースの中で組みなおすことを考えております。

そこで、
・EARが５個あり、すべて同じJVM上で稼動している。
・すべてのEARが、同一のJARを呼び出している。JSPなどは別個にもっている。
以上の条件のとき、JARは実メモリー上では別々にロードされるのでしょうか？
それとも１つだけロードされ、すべてのEARがキャッシングしてくれるのでしょうか？

いろいろ調べたのですが、実メモリーの使い方まで言及してるサイトが見つかりませんでした。。

かなりデカイJAR（パッケージ製品）のため、そこがリソースの大半を占めてしまう見込みです。
尚、これまでは１JVMに１EARにしてました・・・
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-08-28 14:00
別々のClassLoaderで読み込まれているなら多重にメモリに展開されていると思いますね。
もっともClassLoaderにも係争がありますから、上位で読み込まれていれば共有されていると思います。

同一のjarといいますが、フォルダ階層的にはどのように配置しているのでしょうか。
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2007-08-28 15:01
WAS に限った話ではありませんが、基本的に別々の ear に入っているファイルは、中身が同じでも別々のクラスローダでロードされます。
これによりそれぞれ独立してリデプロイを行うことが出来るようになっています。
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-08-28 16:32
引用:

インギさんの書き込み (2007-08-28 15:01) より:
WAS に限った話ではありませんが、基本的に別々の ear に入っているファイルは、中身が同じでも別々のクラスローダでロードされます。
これによりそれぞれ独立してリデプロイを行うことが出来るようになっています。


なるほど。
ClassLoaderの参照範囲は同じだとしても動的リロードのサポートから
推測するにClassLoaderは別インスタンスでしょうね。
Aray
会議室デビュー日: 2007/08/28
投稿数: 3
投稿日時: 2007-08-28 17:08
引用:

nagiseさんの書き込み (2007-08-28 16:32) より:
引用:

インギさんの書き込み (2007-08-28 15:01) より:
WAS に限った話ではありませんが、基本的に別々の ear に入っているファイルは、中身が同じでも別々のクラスローダでロードされます。
これによりそれぞれ独立してリデプロイを行うことが出来るようになっています。


なるほど。
ClassLoaderの参照範囲は同じだとしても動的リロードのサポートから
推測するにClassLoaderは別インスタンスでしょうね。


該当のjarファイルはEarの外に配置（WASのインストールディレクトリの外）し、クラスパスを通して参照してます。
こいつを更新しても動的再ロードされません。（反映にはJVMの再起動が必要）
ということは、逆説的に同じメモリ領域を参照している可能性もありますね。。。
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2007-08-28 22:45
>該当のjarファイルはEarの外に配置（WASのインストールディレクトリの外）し、クラスパスを通して参照して
>ます。
システムクラスパスに通っているクラスは共有されますね。
依存関係のある jar ファイルはすべて ear 内に収めるのが基本ですが。
あしゅ
ぬし
会議室デビュー日: 2005/08/05
投稿数: 613
投稿日時: 2007-08-29 12:11
引用:

Arayさんの書き込み (2007-08-28 17:08) より:
該当のjarファイルはEarの外に配置（WASのインストールディレクトリの外）し、クラスパスを通して参照してます。
こいつを更新しても動的再ロードされません。（反映にはJVMの再起動が必要）
ということは、逆説的に同じメモリ領域を参照している可能性もありますね。。。

WASは随分使っていないので呼び名は憶えていないのですが、
管理コンソールで設定するjarのことですよね？

このクラスローダはEARのクラスローダより上位にいるので、
動的な再ロードはできなかったと思います。

Javaのクラスローダの仕組み的には、ここに配置したjarを動的に
再ロードするには、EARやWARなどの下位のクラスローダに共有されて
いるため、全ての下位クラスローダの再ロードも必要になります。
まあ、これだと実質的に再起動と大差ないですね。

逆に見れば、下位のクラスローダに共有されるので、
・再デプロイ時の動的な更新が必要がない
・異なる複数のバージョンを使い分ける必要がない
・使用メモリ量が多いため、EAR間で共有させたい
・クラス変数を複数のEARのコンテキストで共有させたい
というような状況でのチューニングにも利用できます。

依存関係はなるべくEAR内で解決させた方が扱いやすいので、
ここに配置するのは必要なものだけにとどめるべきですが。
Aray
会議室デビュー日: 2007/08/28
投稿数: 3
投稿日時: 2007-08-29 23:26
引用:

あしゅさんの書き込み (2007-08-29 12:11) より:
引用:

Arayさんの書き込み (2007-08-28 17:08) より:
該当のjarファイルはEarの外に配置（WASのインストールディレクトリの外）し、クラスパスを通して参照してます。
こいつを更新しても動的再ロードされません。（反映にはJVMの再起動が必要）
ということは、逆説的に同じメモリ領域を参照している可能性もありますね。。。

WASは随分使っていないので呼び名は憶えていないのですが、
管理コンソールで設定するjarのことですよね？

このクラスローダはEARのクラスローダより上位にいるので、
動的な再ロードはできなかったと思います。

Javaのクラスローダの仕組み的には、ここに配置したjarを動的に
再ロードするには、EARやWARなどの下位のクラスローダに共有されて
いるため、全ての下位クラスローダの再ロードも必要になります。
まあ、これだと実質的に再起動と大差ないですね。

逆に見れば、下位のクラスローダに共有されるので、
・再デプロイ時の動的な更新が必要がない
・異なる複数のバージョンを使い分ける必要がない
・使用メモリ量が多いため、EAR間で共有させたい
・クラス変数を複数のEARのコンテキストで共有させたい
というような状況でのチューニングにも利用できます。

依存関係はなるべくEAR内で解決させた方が扱いやすいので、
ここに配置するのは必要なものだけにとどめるべきですが。


なるほど、、、
共用できる更新のないモジュールを抽出してみます。

＞ALL
丁寧な回答、ありがとうございました！
1

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