Javaリソースの調整

DataStax Enterpriseでは、デフォルトでガーベージ・ファースト・コレクター（G1）を使用しています。以下の理由で、G1を推奨しています。

• 16 GB～64 GBのヒープ・サイズ。

  G1は最初に、最も大きいガーベージ・オブジェクトを含むヒープの範囲をスキャンし常にヒープのコンパクションを行うため、大型のヒープの場合、CMS（コンカレント・マーク・スイープ）よりもパフォーマンスが優れています。一方で、ガーベージ・コレクションを実行する際、CMSはアプリケーションを停止します。

• ワークロードは変数で、クラスターは常に別のプロセスを実行しています。
• 将来のプルーフィングに備えて、CMSはJava 9で廃止予定です。
• G1は構成が簡単です。
• G1は自己調整します。
• MAX_HEAP_SIZEのみ、設定する必要があります。

ただし、G1にはプロファイリングにより、ある程度のレイテンシーが伴います。

CMSは、以下の環境でのみ、推奨します。

• ガーベージ・コレクションを手動で調整し、テストする時間と専門知識があります。

  ヒープにさらにメモリーを割り当てると、ガーベージ・コレクション機能により、ヒープ・メモリー内のデータベース・メタデータ量が増すため、パフォーマンスが低下する場合がありますのでご注意ください。

• ヒープ・サイズは、16 GB以下です。
• ワークロードは固定で、クラスターは常に同じプロセスを実行しています。
• この環境では、可能な限り最小のレイテンシーが要求されます。

データベースは、この数式に基づいて最大ヒープ・サイズ（MAX_HEAP_SIZE）を自動的に計算します。

max(min(1/2 ram, 1024 megabytes), min(1/4 ram, 32765 megabytes))

実稼働環境で使用する場合、以下のガイドラインに従って環境に応じてヒープ・サイズを調整します。

• ヒープ・サイズは通常、システム・メモリーの¼から½になります。
• オフヒープ・キャッシュおよびファイル・システム・キャッシュでも使用するため、すべてのメモリーをヒープに費やさないでください。
• GCを調整する場合、GCロギングを常に有効にしてください。
• 設定は徐々に調整し、各インクリメンタルの変更をテストします。
• 特にDSE Searchを使用する際は、GCの並列処理を有効にします。
• GCInspectorクラスは、ガーベージ・コレクションに要する時間が200ミリ秒を超えるガーベージ・コレクションに関する情報をログに記録します。ガーベージ・コレクションが頻繁に発生し、完了までにある程度の時間（秒）を要する場合、JVMに対するガーベージ・コレクションの圧力が大きいことを示します。ガーベージ・コレクション・オプションの調整に加え、その他の解決策にはノードの追加やキャッシュ・サイズの縮小があります。
• G1を使用するノードの場合、DataStaxではMAX_HEAP_SIZEを可能な限り大きく（最大で64 GB）することを推奨しています。

推奨される最大ヒープ・サイズは、使用するGCによって異なります。

ハードウェアのセットアップ	推奨のMAX_HEAP_SIZE
G1は最新のコンピューター用（8コア以上）で、最大256 GB RAM	16 GB～32765 MB。 「Javaパフォーマンス調整」を参照してください。
CMSは最新のコンピューター用（8コア以上）で、最大256 GB RAM	16 GB以下。
従来のコンピューター	通常、8 GB。

以下の方法で、環境に応じた最適なヒープ・サイズを特定します。

1. 1つのノードでjvm.optionsファイルの最大ヒープ・サイズを任意の高い値に設定します。たとえば、G1を使用する場合：

   -Xms48G
   -Xmx48G

   ストップ・ザ・ワールドGCの一時停止を避けるために、サイズ変更時は最小値（-Xms）および最大値（-Xmx）のヒープ・サイズを同じ値に設定し、起動時にヒープをメモリー内にロックすることで、スワップアウトを防げます。

2. GCロギングを有効にします。
3. ログを確認して、そのノードが使用しているヒープを表示し、クラスターのヒープ・サイズを設定する上でこの値を使用します。

CMSの場合、HEAP_NEWSIZEも調整する必要があります。この設定により、新しいオブジェクトまたはyoung generationに割り当てられるヒープ・メモリーの量が決まります。データベースは、以下の2つの少ない方でこのプロパティのデフォルト値をメガバイト単位（MB）で計算します。

• コア数の100倍
• MAX_HEAP_SIZEの¼

開始点として、物理的CPUコアごとにHEAP_NEWSIZEを100 MBに設定します。たとえば、最新の8コア+マシンの場合：

-Xmn800M

データベースは、JVM内で以下のメジャー・コンパクションを実行します。

• 読み取りを実行するために、データベースはヒープ・メモリー内で以下のコンポーネントを維持します。
  • ブルーム・フィルター
  • パーティション・サマリー
  • パーティション・キー・キャッシュ
  • 圧縮オフセット
  • SSTableインデックス・サマリー

  このメタデータは、メモリーに常駐し、データの合計に比例します。一部のコンポーネントは、メモリーの合計サイズに比例して大きくなります。

• データベースは読み取りまたはアンチエントロピー・リペア用のレプリカを収集し、ヒープ・メモリー内でレプリカを比較します。
• データベースに書き込まれたデータは、最初にヒープ・メモリー内のmemtableに格納されます。memtableは、ディスクのSSTableにフラッシュされます。

パフォーマンスを改善するには、次のようにデータベースはオフヒープ・メモリーを使用します。

• ページのキャッシュ。データベースは、ディスク上のファイルを読み取ったときに、追加メモリーをページのキャッシュとして利用します。
• ブルーム・フィルターと圧縮オフセット・マップはオフヒープに置かれます。
• データベースは、キャッシュされた行をネイティブのメモリー、Javaヒープ外に格納します。これにより、JVMヒープに対する要求がともに小さくなります。これは、JVMガーベージ・コレクションのパフォーマンスにとって最適なヒープ・サイズを保つのに役立ちます。