WebSphere® eXtreme Scale は、特定の BackingMap の Java ヒープ・メモリーの使用量 (バイト単位) を正確に見積もることができます。この機能を使用して、Java 仮想マシンのヒープ設定および除去ポリシーを正しくサイズ設定してください。 この機能の動作は、バックアップ・マップに配置されるオブジェクトの複雑さおよびマップの構成方法によって異なります。 現在、この機能は分散データ・グリッドのみでサポートされています。 ローカル・データ・グリッドのインスタンスは使用バイトの見積もりをサポートしません。
見積もり統計によって報告される使用バイト数は、これら 4 つの構成要素の合計です。 これらの値は、マップの挿入、更新、および除去の操作を基にしてエントリーごとに計算されます。すなわち、eXtreme Scale は、特定のバッキング・マップが消費するバイト数のための現行値を常に持っています。
データ・グリッドが区画に分割されている場合、各区画にはバッキング・マップの一部が含まれます。 見積もり統計は最下位の eXtreme Scale コードで計算されるため、バッキング・マップの各区画は自分自身のサイズを追跡します。eXtreme Scale 統計 API を使用すると、個々の区画のサイズと同様に、マップの累積サイズを追跡できます。
一般に、見積もりデータは、一定時間におけるデータの傾向の指標として使用し、マップによって使用されているヒープ・スペースの正確な測定としては使用されません。例えば、マップの報告されたサイズが 5 MB から 10 MB に 2 倍になると、マップのメモリー消費量は 2 倍になるかのように表示されます。 実測値の 10 MB は、複数の理由から正確でない場合があります。この理由を考慮してベスト・プラクティスに従えば、サイズ測定の精度は Java ヒープ・ダンプの後処理の精度に近づきます。
より正確な統計を提供できる設計選択、ベスト・プラクティス、および実装選択の理解からあいまいさがなくならない限り、このあいまいさのために上記の測定は傾向データとして考えられてしまいます。
eXtreme Scale は、特定のマップに含まれるキー・オブジェクトまたは値オブジェクトへの参照のうち、長く存続する参照だけをそのマップは保持すると想定します。 同じ 5 KB オブジェクトを 3 つのマップに入れた場合、各マップのサイズは 5 KB ずつ増加します。 この増加は、通常問題ではありません。この機能は分散データ・グリッドでのみサポートされているからです。 リモート・クライアント上にある 3 つの異なるマップに同じオブジェクトを挿入すると、各マップはそのオブジェクトの独自のコピーを受け取ります。 デフォルト・トランザクションの COPY MODE 設定も、各マップがある特定のオブジェクトの独自のコピーを持つことを通常保証します。
public class ShippingOrder implements Serializeable,Cloneable{
public static final STATE_NEW = “new”;
public static final STATE_PROCESSING = “processing”;
public static final STATE_SHIPPED = “shipped”;
private String state;
private int orderNumber;
private int customerNumber;
public Object clone(){
ShippingOrder toReturn = new ShippingOrder();
toReturn.state = this.state;
toReturn.orderNumber = this.orderNumber;
toReturn.customerNumber = this.customerNumber;
return toReturn;
}
private void readResolve(){
if (this.state.equalsIgnoreCase(“new”)
this.state = STATE_NEW;
else if (this.state.equalsIgnoreCase(“processing”)
this.state = STATE_PROCESSING;
else if (this.state.equalsIgnoreCase(“shipped”)
this.state = STATE_SHIPPED:
}
}
エントリー数やヒット率など、単一マップの統計を提供する MapStatsModule.getUsedBytes() メソッドを使用します。
詳しくは、統計モジュールを参照してください。
管理対象 MBean 統計の MapUsedBytes を使用します。 デプロイメントを管理およびモニターするには、さまざまなタイプの Java Management Extensions (JMX) MBeans を使用できます。 各 MBean は、マップ、eXtreme Scale、サーバー、レプリカ生成グループ、またはレプリカ生成グループ・メンバーなどの特定のエンティティーを参照します。
詳しくは、Managed Beans (MBeans) を使用した管理を参照してください。
PMI モジュールを使用してアプリケーションのパフォーマンスをモニターすることができます。 特に、WebSphere Application Server に組み込まれているコンテナーに対してマップ PMI モジュールを使用します。
詳しくは、PMI モジュールを参照してください。
コンソールで、メモリー消費量の統計を表示できます。 Web コンソールによるモニターを参照してください。
上記すべての方法で、特定の BaseMap インスタンスのメモリー消費量の、基本となる同一の測定が利用できます。WebSphere eXtreme Scale ランタイムは、マップそのもののオーバーヘッドと同様に、マップに保管されたキー・オブジェクトおよび値オブジェクトが消費するヒープ・メモリーのバイト数をベストエフォートで計算しようとします。分散データ・グリッド全体で各マップが消費しているヒープ・メモリーの量を表示することができます。
多くの場合、指定のマップに対して WebSphere eXtreme Scale が報告する値は、ヒープ・ダンプ分析によって報告される値と非常に近いものになります。 WebSphere eXtreme Scale は自分自身のオーバーヘッドを正確に見積もりますが、マップに入れられる可能性のあるすべてのオブジェクトを明らかにすることはできません。 正確なメモリー消費予測のために、キャッシュ・サイジング・エージェントをチューニングするで説明されているベスト・プラクティスに従えば、WebSphere eXtreme Scale で提供されるバイト測定において、見積もりの精度を向上させることができます。