Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP- UX Developer Edge

J2EE運用の新しい常識、「パーティショニング」を検証する

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
Install Time SecurityとBastilleで実現する盤石のホスト構築 HP-UXで実現するネットワーク&セキュリティ
コンソリデーション(IT統合)の普及により、4-wayを越えるマルチプロセッサー・サーバでJ2EEサーバを運用する事例が増えている。しかし、単にプロセッサー数を増やすだけではJ2EEの性能はすぐに頭打ちになってしまい、「パーティショニング」の概念を導入しない限り、この壁は突破できないのである。ここでは、来日した米国HPのJVM関連の主任エンジニアであるジョゼフ・コア(Joseph Coha)氏へのインタビューを元に、HP-UXに導入されているパーティショニングのメカニズム、「プロセッサー・セット(pset)」と「Cell Local Memory」にスポットを当て、コンソリデーション時代のJ2EE運用ノウハウを明らかにする。
J2EE運用の新しい常識、「パーティショニング」を検証する
J2EEに立ちふさがる「壁」
「パーティショニング」を導入せよ
   
   
2004年6月
テクニカルライター:吉川 和巳

J2EEに立ちふさがる「壁」


4-wayを越えるようなマルチプロセッサー・サーバでは、J2EEサーバのスケールアップを阻む大きな「壁」が立ちはだかる。まずは、この壁の実態をつかむために、図1を見ていただきたい。

図1:プロセッサー増設時のJ2EEサーバのスケーラビリティ低下
図1:プロセッサー増設時のJ2EEサーバのスケーラビリティ低下

図1は、プロセッサー数を1から4まで変化させた場合に、J2EEサーバのスケーラビリティ(ユーザ数に対するスループット)にどのような影響が現れるのかを計測したグラフだ。このグラフから分かるように、1 CPUおよび2 CPUのケースではパフォーマンス上の問題はないものの、4 CPUではスケーラビリティが極端に低下してしまう。本来であれば、4 CPUの構成では、2 CPU構成に対して2倍程度のパフォーマンスを維持することが期待される。しかし現実には、同時アクセスするユーザ数が増えるとともにCPUの利用率が低下し、ハードウェアのパフォーマンスをフルに引き出せなくなるのだ。

では、CPU以外の何がボトルネックとなるのだろうか。米国HPにおいてJavaパフォーマンス・チューニングのコンサルティングやツール開発に携わるエンジニア、ジョゼフ・コア(Joseph Coha)氏は、その答えが「ロック競合」であると説明する。

写真1:筆者のインタビューに答えるジョゼフ・コア(Joseph Coha)氏。
写真1: 筆者のインタビューに答えるジョゼフ・コア(Joseph Coha)氏。
米国HPにおいてJavaパフォーマンス・チューニングのコンサルティングやツール開発に携わる主任エンジニアだ

Java仮想マシン(JVM)の内部では、複数のスレッドが同時アクセスするオブジェクトに対してロックをかけることが頻繁に行われる。図2のように、いずれか1つのスレッドがオブジェクトをロックすることで、他のスレッドがアクセスできない状況を一時的に作り出すのである。

図2:ロックによるマルチスレッドの同期化
図2:ロックによるマルチスレッドの同期化

このとき、もしロックされたオブジェクトに他のスレッドがアクセスしようとすると、そのスレッドはロックが解放されるまで一時停止しなくてはならない。これが、JVMにおけるロック競合である。

実のところ、シングル・プロセッサー構成のサーバでは、アプリケーションの設計に問題がない限り、ロック競合がボトルネックとなることは少ない。しかしコア氏は、「マルチプロセッサー・サーバではわずかなロック競合がスケーラビリティに大きな影響を及ぼす」と指摘する。

 
 

キャッシュ整合性の維持がボトルネックに


その理由を明らかにするため、OSカーネル内部におけるロックのメカニズムに注目しよう。JVM実装の多くでは、OSに備わるミューテックス(排他制御の機構)によってJavaオブジェクトのロックが実現されている。具体的には、ミューテックスを利用してメモリ上の1ワードをロックすることで、オブジェクトのロックを表現するのである。

問題となるのは、このミューテックスによるロック競合で一時停止させられるスレッドの扱いだ。一時停止したスレッドは、ロックが解放されるまでスリープ状態とされる。しかし、スレッドのスリープや再起動はOSにとってオーバーヘッドの大きい処理であるため、現在のUNIX OSの多くは「スピン・ロック(spin lock)」と呼ばれるメカニズムを合わせて利用している。つまり、スレッドを実際にスリープさせる前に、ロックの状態をつねに監視しつづけるループを一定回数だけ実行させる仕組みだ。多くの場合、このスピン・ロック中にロックが解放されるので、スレッドを毎回スリープさせるよりも効率がよいのである。

スピン・ロックの間、待ち状態にある全てのスレッドは上述したメモリ上の1ワードに繰り返しアクセスすることになる。これは、シングル・プロセッサー構成では難なく実行できる処理だ。だがマルチプロセッサー構成では、個々のCPUに付属するキャッシュ間で、メモリ内容に対する整合性(キャッシュ・コヒーレンシー)の維持が必要になる。具体的には、その1ワードをめぐってキャッシュ間のアクセス調停やコピーをきわめて高い頻度で繰り返さなくてはならない(図3)。さらにこの負荷は、プロセッサー数の増加にともない指数的に拡大する。これが、4-wayを越えるマルチプロセッサー・サーバにおいてロック競合がボトルネックになる原因であると、コア氏は指摘する。

図3:プロセッサー間のキャッシュ・コヒーレンシー維持
図3:プロセッサー間のキャッシュ・コヒーレンシー維持

トップへ   次のページへ ※本文の続きを閲覧するには、HP-UX Developer Edgeへの会員登録が必要です。

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

HPEサポートセンター
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項