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

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

図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)氏。 米国HPにおいてJavaパフォーマンス・チューニングのコンサルティングやツール開発に携わる主任エンジニアだ

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

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

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

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

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

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

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

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