メモリー・サイズ設定および区画数の計算

特定の構成に必要なメモリーの容量および区画数を計算できます。

重要: このトピックは、COPY_TO_BYTES コピー・モードを使用していないときに当てはまります。 COPY_TO_BYTES モードを使用している場合は、メモリー・サイズがはるかに小さくなり、計算手順が異なります。このモードについて詳しくは、コピー・モードのチューニングを参照してください。
WebSphere eXtreme Scale は、データを Java 仮想マシン (JVM) のアドレス・スペースに保管します。各 JVM は、JVM に保管されたデータの作成、取得、更新、および削除の呼び出しをサービスするためのプロセッサー・スペースを提供します。 さらに、各 JVM は、データ・エントリーおよびレプリカ用のメモリー・スペースを提供します。Java オブジェクトのサイズはさまざまな ので、必要なメモリー量を見積もるための測定が必要です。

必要なメモリーのサイズを設定するには、アプリケーション・データを 1 つの JVM にロードします。ヒープ使用量が 60% に達している場合、使用されるオブジェクトの数に注意してください。 この数値は、Java 仮想マシン のそれぞれの推奨されるオブジェクトの最大数です。最も的確なサイズ設定を行うには、現実に近いデータを使用します。索引もまたメモリーを消費するので、定義されているすべての索引をサイズ設定に含めてください。メモリー使用量のサイズ見積もり を行う最良の方法は、ガーベッジ・コレクション verbosegc 出力を実行することです。この出力 によって、ガーベッジ・コレクション後の数値が分かるからです。ヒープ使用量に ついては MBean またはプログラムでいつでも照会できますが、そういった照会ではヒープの現行スナップショットしか取得できません。このスナップショットには未収集のガーベッジが含まれている可能性があるため、この方法では消費メモリーは正確には示されません。

構成の拡張

区画当たりの断片数 (numShardsPerPartition 値)
区画当たりの 断片数である numShardsPerPartition 値を 計算するには、プライマリー断片の 1 に、必要なレプリカ断片の総数を 加算します。区画化について詳しくは、区画化を参照してください。
numShardsPerPartition = 1 + total_number_of_replicas

Java 仮想マシン 数 (minNumJVMs 値)

構成を拡張するには、まず保管する必要のある合計オブジェクトの最大数を決定します。必要 な Java 仮想マシンの数を決めるには、 次の式を使用します。
minNumJVMS=(numShardsPerPartition * numObjs) / numObjsPerJVM
この値を切り上げて、最も近い整数値にしてください。

断片数 (numShards 値)

最終的な増加サイズでは、それぞれの JVM に 10 個の断片を使用します。前述したように、各 JVM には、1 つのプライマリー断片と (N-1) 個のレプリカ断片があります。この場合、9 個のレプリカがあります。データ保管用に既に多数の Java 仮想マシンがある ため、Java 仮想マシンの数に 10 を掛けて、断片の 数を決定することができます。
numShards = minNumJVMs * 10 shards/JVM

区画数

区画に 1 つのプライマリー断片と 1 つのレプリカ断片がある場合、区画には 2 つの断片 (プライマリーとレプリカ) があります。区画数は、断片数を 2 で割って、一番近い素数に丸めたものです。 区画に 1 つのプライマリーと 2 つのレプリカがある場合、区画数は、断片数を 3 で割って、一番近い素数に丸めたものになります。
numPartitions = numShards / numShardsPerPartition

拡張の例

この例では、エントリー数は当初 250,000,000 であるとします。毎年、エントリー数は 14% 増加します。7 年後には、エントリーの合計数が 500,000,000 となるため、それに応じた容量計画が必要になります。 高可用性を実現するため、1 つのレプリカが必要になります。 レプリカを使用すると、エントリー数は 2 倍、すなわち 1,000,000,000 となります。 テストとして、2,000,000 のエントリーを各 JVM に保管できます。このシナリオの計算を使用すると、以下の構成が必要になります。

構成の開始

前述の計算 に基づいて、250 の Java 仮想マシンから始めて、5 年間 で 500 の Java 仮想マシンに増やします。 この構成を使用して、最終的なエントリー数に達するまで段階的な増加を管理 できます。

この構成では、区画ごとに約 200,000 (500,000,000 のエントリーを区画数の 2503 で割ったもの) のエントリーが保管されます。numberOfBuckets パラメーターを次位の素数 (この例では 70887) までのエントリーを収めるマップで設定します。これにより約 3 の比率が保たれます。

Java 仮想マシンの最大数に達した場合

500 という Java 仮想マシンの最大数に達しても、データ・グリッドを拡張できます。Java 仮想マシン の数が 500 を超えるまでになると、各 JVM について断片数が 10 (推奨数) を下回り始めます。つまり断片が大きくなり始めます。これは問題となる場合があります。将来の成長を考慮しながら、サイズ設定処理を繰り返し、区画数を設定し直します。この作業では、データ・グリッド全体の再始動が必要になります。さもないとデータ・グリッド不足となります。

サーバー数

重要: どのような場合にも、サーバーについてはページングは使用しないでください。
1 つの JVM は、ヒープ・サイズを超えるメモリーを使用します。例えば、JVM の 1 GB のヒープでは、実際には 1.4 GB の実メモリーが使用されます。サーバー上の使用可能な空き RAM を判別してください。RAM の容量を JVM あたりのメモリーで割って、サーバー上の Java 仮想マシンの最大数を計算してください。