キャッシュ・メモリー消費量の見積もり

WebSphere® eXtreme Scale は、特定の BackingMap の Java ヒープ・メモリーの使用量 (バイト単位) を正確に見積もることができます。この機能を使用して、Java 仮想マシンのヒープ設定および除去ポリシーを正しくサイズ設定してください。 この機能の動作は、バックアップ・マップに配置されるオブジェクトの複雑さおよびマップの構成方法によって異なります。 現在、この機能は分散データ・グリッドのみでサポートされています。 ローカル・データ・グリッドのインスタンスは使用バイトの見積もりをサポートしません。

ヒープ消費量に関する考慮事項

eXtreme Scale は、データ・グリッドを構成する JVM プロセスのヒープ・スペース内に、所有するすべてのデータを保管します。特定のマップの場合、そのマップが消費するヒープ・スペースは、以下のコンポーネントに分割できます。
  • 現在マップ内に存在するすべてのキー・オブジェクトのサイズ
  • 現在マップ内に存在するすべての値オブジェクトのサイズ
  • マップ上の Evictor プラグインによって使用中のすべての EvictorData オブジェクトのサイズ
  • 基本データ構造のオーバーヘッド

見積もり統計によって報告される使用バイト数は、これら 4 つの構成要素の合計です。 これらの値は、マップの挿入、更新、および除去の操作を基にしてエントリーごとに計算されます。すなわち、eXtreme Scale は、特定のバッキング・マップが消費するバイト数のための現行値を常に持っています。

データ・グリッドが区画に分割されている場合、各区画にはバッキング・マップの一部が含まれます。 見積もり統計は最下位の eXtreme Scale コードで計算されるため、バッキング・マップの各区画は自分自身のサイズを追跡します。eXtreme Scale 統計 API を使用すると、個々の区画のサイズと同様に、マップの累積サイズを追跡できます。

一般に、見積もりデータは、一定時間におけるデータの傾向の指標として使用し、マップによって使用されているヒープ・スペースの正確な測定としては使用されません。例えば、マップの報告されたサイズが 5 MB から 10 MB に 2 倍になると、マップのメモリー消費量は 2 倍になるかのように表示されます。 実測値の 10 MB は、複数の理由から正確でない場合があります。この理由を考慮してベスト・プラクティスに従えば、サイズ測定の精度は Java ヒープ・ダンプの後処理の精度に近づきます。

精度に関する主要な問題は、Java Memory Model は、非常に正確なメモリー測定を可能にするほど制限されていないことです。 基本的な問題は、オブジェクトは複数参照のためにヒープ上でライブになっている可能性があるということです。 例えば、同じ 5 KB のオブジェクト・インスタンスを 3 つの別々のマップに挿入すると、この 3 つのマップのいずれかはオブジェクトがガーベッジ・コレクションされないようにします。 この場合、以下のいずれかの測定が正当だと思われます。
  • 各マップのサイズは 5 KB ずつ増加します。
  • オブジェクトが最初に配置されるマップのサイズは 5 KB ずつ増加します。
  • 他の 2 つのマップのサイズは増加しません。 各マップのサイズはオブジェクトのサイズの何分の 1 かずつ増加します。

より正確な統計を提供できる設計選択、ベスト・プラクティス、および実装選択の理解からあいまいさがなくならない限り、このあいまいさのために上記の測定は傾向データとして考えられてしまいます。

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:
     }
 }
eXtreme Scale はオブジェクトが異なるメモリー・ロケーションを使用していると想定しているため、オブジェクト収容は見積もり統計による過大見積もりを引き起こしてしまいます。100 万個の ShippingOrder オブジェクトがある場合、見積もり統計には、状態情報を保持する 100 万個のストリングのコストが示されます。実際は、静的クラス・メンバーである 3 個のストリングしか存在していません。静的クラス・メンバーのメモリー・コストは、いずれの eXtreme Scale マップにも追加されるべきではありません。しかし、実行時にこの状況は検出できません。同様のオブジェクト収容を実装できる方法がたくさんあるため、検出はとても困難です。eXtreme Scale が可能なすべての実装から保護することは実用的ではありません。 ただし、eXtreme Scale は、最もよく使用されるタイプのオブジェクト収容から保護します。オブジェクト収容を使用してメモリー使用量を最適化するには、以下の 2 つのカテゴリーに入るカスタム・オブジェクトにのみ収容を実装して、メモリー消費量の統計の精度を向上させます。
  • eXtreme Scale は、『Java 2 Platform Standard Edition 5.0 の概要: 列挙型』で説明があるように、自動的に Java 5 列挙型および Typesafe Enum パターンを調整します。
  • eXtreme Scale は、自動的に Integer などのプリミティブ・ラッパー・タイプの自動収容を明らかにします。プリミティブ・ラッパー・タイプの自動収容は、Java 5 で静的 valueOf メソッドの使用を介して導入されました。

メモリー消費量の統計

以下のいずれかの方法を使用して、メモリー消費量の統計にアクセスします。
統計 API

エントリー数やヒット率など、単一マップの統計を提供する MapStatsModule.getUsedBytes() メソッドを使用します。

詳しくは、統計モジュールを参照してください。

Managed Bean (MBean)

管理対象 MBean 統計の MapUsedBytes を使用します。 デプロイメントを管理およびモニターするには、さまざまなタイプの Java Management Extensions (JMX) MBeans を使用できます。 各 MBean は、マップ、eXtreme Scale、サーバー、レプリカ生成グループ、またはレプリカ生成グループ・メンバーなどの特定のエンティティーを参照します。

詳しくは、Managed Beans (MBeans) を使用した管理を参照してください。

Performance Monitoring Infrastructure (PMI) モジュール

PMI モジュールを使用してアプリケーションのパフォーマンスをモニターすることができます。 特に、WebSphere Application Server に組み込まれているコンテナーに対してマップ PMI モジュールを使用します。

詳しくは、PMI モジュールを参照してください。

WebSphere eXtreme Scale コンソール

コンソールで、メモリー消費量の統計を表示できます。 Web コンソールによるモニターを参照してください。

上記すべての方法で、特定の BaseMap インスタンスのメモリー消費量の、基本となる同一の測定が利用できます。WebSphere eXtreme Scale ランタイムは、マップそのもののオーバーヘッドと同様に、マップに保管されたキー・オブジェクトおよび値オブジェクトが消費するヒープ・メモリーのバイト数をベストエフォートで計算しようとします。分散データ・グリッド全体で各マップが消費しているヒープ・メモリーの量を表示することができます。

多くの場合、指定のマップに対して WebSphere eXtreme Scale が報告する値は、ヒープ・ダンプ分析によって報告される値と非常に近いものになります。 WebSphere eXtreme Scale は自分自身のオーバーヘッドを正確に見積もりますが、マップに入れられる可能性のあるすべてのオブジェクトを明らかにすることはできません。 正確なメモリー消費予測のために、キャッシュ・サイジング・エージェントをチューニングするで説明されているベスト・プラクティスに従えば、WebSphere eXtreme Scale で提供されるバイト測定において、見積もりの精度を向上させることができます。