Red Hat Summit2.2. データセットのサイズを計算する方法
Data Grid デプロイメントのプランニングでは、データセットのサイズを計算してから、適切なノード数と、データセットを保持する RAM の容量を測定する必要があります。
以下の式を使用して、データセットの合計の概算サイズを予測できます。
Data set size = Number of entries * (Average key size + Average value size + Memory overhead)
リモートキャッシュでは、マーシャリング形式で鍵のサイズと値サイズを計算する必要があります。
分散キャッシュのデータセットサイズ
分散キャッシュには、データセットサイズを判断するために追加の計算が必要です。
通常の運用条件では、分散キャッシュは、設定する 所有者の数 と等しい各キー/値エントリーのコピーを多数保存します。クラスターのリバランス操作時に、追加のコピーがあるエントリーもあるので、所有者数 + 1 を算出してそのシナリオを許可する必要があります。
以下の式を使用して、分散キャッシュのデータセットサイズの推定を調整できます。
Distributed data set size = Data set size * (Number of owners + 1)
分散キャッシュでの利用可能なメモリーの計算
分散キャッシュを使用すると、ノードを追加するか、ノードごとに利用可能なメモリーの量を増やすことで、データセットサイズを増やすことができます。
Distributed data set size <= Available memory per node * Minimum number of nodes
ノードの損失への耐性調整
クラスター内に特定のノード数を配置するように計画する場合でも、すべてのノードがクラスターに常に存在するわけではない点を考慮する必要があります。分散キャッシュは、データが損失することなく、所有者数 - 1 分の損失に対応します。そのため、データセットに必要な最小ノード数に加え、その分を余分に割り当てるようにしてください。
Planned nodes = Minimum number of nodes + Number of owners - 1 Distributed data set size <= Available memory per node * (Planned nodes - Number of owners + 1)
たとえば、サイズが 10KB の 100 万のエントリーを保存して、エントリーごとに 3 つの所有者を設定する計画を予定します。クラスター内の各ノードに 4 GB の RAM を割り当てる予定の場合には、以下の式を使用してデータセットに必要なノード数を判断できます。
Data set size = 1_000_000 * 10KB = 10GB Distributed data set size = (3 + 1) * 10GB = 40GB 40GB <= 4GB * Minimum number of nodes Minimum number of nodes >= 40GB / 4GB = 10 Planned nodes = 10 + 3 - 1 = 12
2.2.1. メモリーのオーバーヘッド
メモリーのオーバーヘッドは、Data Grid がエントリーを保存するために使用する追加のメモリーです。メモリーのオーバーヘッドの概算値は、JMV ヒープメモリーのエントリーごとに 200 バイトまたは、オフヒープメモリーのエントリーごとに 60 バイトです。ただし、Data Grid がエントリーごとに追加するオーバーヘッドは、複数の要因によって異なるため、メモリーのオーバーヘッドを正確に決定することはできません。たとえば、エビクションでデータをバインドすると、Data Grid は追加のメモリーを使用してエントリーを追跡します。同様に、有効期限を設定すると、タイムスタンプのメタデータが各エントリーに追加されます。
種類に関係なく、メモリーのオーバーヘッドの実際の量を見つけ出す唯一の方法として、JVM ヒープダンプ分析が行われます。当然、JVM ヒープダンプでは、オフヒープメモリーに格納するエントリーの情報はありませんが、メモリーのオーバーヘッドは JVM ヒープメモリーよりも大幅に小さくなります。
追加のメモリー使用量
Data Grid がエントリーごとに課すメモリーオーバーヘッドに加え、リバランスやインデックスなどのプロセスの全体的なメモリー使用量が増える可能性があります。ノードの参加時や退出時にクラスターの操作をリバランスすると、クラスターメンバー間のエントリーを複製している間にデータが損失されないように、一時的に余分な容量が必要になります。
2.2.2. JVM ヒープ領域の割り当て
要件対応に十分なデータストレージ容量を確保できるように、Data Grid のデプロイメントに必要なメモリーの量を決定します。
ガベージコレクション (GC) 時間の設定と組み合わせて大きなメモリーヒープサイズを割り当てると、Data Grid デプロイメントのパフォーマンスに次のような影響を与える可能性があります。
- JVM が 1 つのスレッドしか処理しない場合、GC がスレッドをブロックし、JVM のパフォーマンスを低下させる可能性があります。GC はデプロイ前に動作する場合があります。この非同期動作により、大規模な GC 一時停止が発生する可能性があります。
- CPU リソースが少なく、GC がデプロイと同期して動作する場合、GC はより頻繁に実行する必要があり、デプロイのパフォーマンスが低下する可能性があります。
次の表に、データストレージ用の JVM ヒープ領域を割り当てる 2 つの例を示します。これらの例は、クラスターを安全にデプロイするための想定要件を表しています。
| 読み取り、書き込み、削除操作などのキャッシュ操作のみ。 | データストレージに JVM ヒープ領域の 50% を割り当てる |
| キャッシュ操作およびクエリーやキャッシュイベントリスナーなどのデータ処理 | データストレージに JVM ヒープ領域の 33% を割り当てる |
パターンの変更とデータストレージの使用状況に応じて、推奨される安全な見積もりとは異なる割合を JVM ヒープ領域に設定することを検討してください。
Data Grid のデプロイメントを開始する前に、安全な見積もりを設定することを検討してください。デプロイを開始したら、JVM のパフォーマンスとヒープスペースの占有率を確認します。JVM のデータ使用量とスループットが大幅に増加した場合、JVM ヒープ領域の再調整が必要になる場合があります。
安全な見積もりは、次の一般的な操作が JVM 内で実行されているという前提で計算されました。リストは完全なものではなく、追加の操作を実行する目的で、これらの安全な見積もりのいずれかを設定する場合があります。
- Data Grid は、シリアル化された形式のオブジェクトをキーと値のペアに変換します。Data Grid は、ペアをキャッシュと永続ストレージに追加します。
- Data Grid は、リモート接続からクライアントへのキャッシュを暗号化および復号化します。
- Data Grid は、キャッシュの定期的なクエリーを実行してデータを収集します。
- Data Grid は、データを戦略的にセグメントに分割して、状態遷移操作中であってもクラスター間でデータを効率的に分散できるようにします。
- JVM が GC 操作に大量のメモリーを割り当てたため、GC はより頻繁にガベージコレクションを実行します。
- GC は、JVM ヒープスペース内のデータオブジェクトを動的に管理および監視して、未使用のオブジェクトを安全に削除できるようにします。
データストレージに JVM ヒープスペースを割り当てるとき、および Data Grid デプロイメントのメモリーボリュームと CPU 要件を決定するときは、次の要素を考慮してください。
- クラスター化されたキャッシュモード
セグメント数
- たとえば、セグメント数が少ないと、サーバーがノード間でデータを分散する方法に影響を与える可能性があります。
- 読み取りまたは書き込み操作。
リバランス要件。
- たとえば、状態の転送中に多数のスレッドが並列ですばやく実行される可能性がありますが、各スレッド操作はより多くのメモリーを使用する可能性があります。
- クラスターのスケーリング
- 同期または非同期のレプリケーション
最も主要な Data Grid 操作で、CPU リソースを多く必要とするものには、Pod の再起動後のノードのリバランス、データに対するインデックスクエリーの実行、GC 操作の実行などが挙げられます。
オフヒープストレージ
Data Grid はオブジェクトの JVM ヒープ表現を使用して、キャッシュでの読み取りおよび書き込み操作を処理したり、状態遷移操作などの他の操作を実行します。エントリーをオフヒープメモリーに保存していても、JVM ヒープ領域を Data Grid に常に割り当てる必要があります。
Data Grid がオフヒープストレージで使用する JVM ヒープメモリーの量は、JVM ヒープスペースにデータを格納する場合と比べてはるかに小さくなります。オフヒープストレージの JVM ヒープメモリー要件は、格納されているエントリーの数に対する同時操作の数に比例します。
Data Grid はトポロジーキャッシュを使用して、クライアントにクラスタービューを提供します。
Data Grid クラスターから OutOfMemoryError 例外を受け取った場合は、次のオプションを検討してください。
- 状態遷移操作を無効にします。これにより、ノードがクラスターに参加またはクラスターから離脱した場合にデータが失われる可能性があります。
- キーサイズとノードおよびセグメントの数を考慮して、JVM ヒープスペースを再計算します。
- より多くのノードを使用して、クラスターのメモリー消費をより適切に管理します。
- メモリー使用量が少なくて済む可能性があるため、単一ノードを使用します。ただし、クラスターを元のサイズにスケーリングする場合は、影響を考慮してください。
