1. 管理者ガイド
  2. チューニング
  3. オフヒープ・キャッシュの管理

オフヒープ・キャッシュの管理

ストアの各レプリケーション・ノードは、使用可能なメモリーを、ストア・オブジェクトを含むメモリー、ホスト・オペレーティング・システムによって使用されるメモリー(ファイル・システム・キャッシュを含む)、および頻繁にアクセスされるストア・データの格納に使用されるインメモリー・キャッシュに分割します。キャッシュによって使用されるメモリー容量は、rnHeapPercentパラメータを使用して構成できます。このパラメータの値は、レプリケーション・ノード(RN)で使用可能な合計メモリーのパーセンテージとして表されます。つまり、RNで使用可能なメモリーは、Java VMで使用可能としてメモリー容量によって決まります。デフォルトでは、レプリケーション・ノードで使用可能なメモリーの70%がインメモリー・キャッシュのために確保されます。

ただし、これが一杯になる可能性はあります。その場合は、Least-Recently-Used (LRU)アルゴリズムに基づいてオブジェクトがキャッシュから削除されます。よくアクセスされるオブジェクトは、LRUアルゴリズムにより確実にキャッシュに残されます。

オーバーフローしないようにインメモリー・キャッシュに特に大きな容量を設定してレプリケーション・ノードを構成することは可能です。ただし、キャッシュが大きくなりすぎると、いくつかのデメリットが発生します。最も重要なのは、キャッシュが大きいと、Javaガベージ・コレクションのパフォーマンスが低下することです。これによって、レプリケーション・ノード全体のパフォーマンスが悪影響を受けます。一般的には、ヒープ・サイズを32GB未満に保つことをお薦めします。これにより、インメモリー・キャッシュは約22.4GBに制限されます。

注意:

Oracle NoSQL Databaseでは、実際には最大ヒープ・サイズをデフォルト値の32GBに制限して、大きすぎるキャッシュを誤って作成しないようにしています。最大ヒープ・サイズの値は、この項で後述するrnHeapMaxMBパラメータを使用して管理します。

レプリケーション・ノードのヒープ・サイズを小さくする場合は、使用されていないヒープ・メモリーがオペレーティング・システムとファイル・システム・キャッシュで使用されるようにシステムを構成できます。大きなファイル・システム・キャッシュにはパフォーマンスのメリットがありますが、次のようなデメリットもあります。

  1. メイン・キャッシュとファイル・システム・キャッシュの間の冗長性が高くなります。レプリケーション・ノードによって書き込まれるすべてのデータとBツリー情報がファイル・システムにもメイン・キャッシュにも含まれるためです。
  2. ダーティBツリー情報をロギングせずにファイル・システム・キャッシュに配置することはできません。このようなロギングは不要である可能性があり、これによって内部クリーナ・スレッドの追加処理が発生することがあります。

インメモリー・キャッシュとファイル・システム・キャッシュが大きすぎるせいで発生する問題を回避するために、レプリケーション・ノードのデフォルト構成ではオフヒープ・キャッシュが使用されます。オフヒープ・キャッシュを使用して、オーバーフローした場合にメイン・キャッシュから削除されるレコード・データとBツリー・ノードを格納します。オフヒープ・キャッシュがオーバーフローした場合は、メイン・キャッシュで使用されるものと同じLRUアルゴリズムに基づいて削除が発生します。

使用可能なメモリーがないためにオフヒープ割当て(またはその他)が失敗する場合、プロセスは例外をスローすることなく停止する可能性が高くなります。たとえば、Linuxで行われたあるテストでは、プロセスがOSによって突然強制終了されました。この問題の唯一の兆候として、dmesgによって次の情報が示されました。

 Out of memory: Kill process 28768 (java) score 974 or sacrifice child
 Killed process 28768 (java)
    total-vm:278255336kB, anon-rss:257274420kB, file-rss:0kB

注意:

本番ストアで使用されているキャッシュを変更する前に、常にパフォーマンス・テストを完了してください。

オフヒープ・キャッシュの構成

オフヒープ・キャッシュで使用可能なメモリー容量を直接制御することはできません。このメモリーを設定するには、主としてオペレーティング・システムで使用可能なメモリー容量を制限します。また、場合によってはJavaヒープのサイズを制御する必要もあります。これによって、インメモリー・キャッシュのサイズが制御されます。ヒープ、JVMオーバーヘッドおよびオペレーティング・システムの要件が満たされた後で残ったストレージ・ノード・メモリーがオフヒープ・キャッシュに使用されます。ヒープとオペレーティング・システムの要件が満たされた後、残ったレプリケーション・ノード・メモリーがオフヒープ・キャッシュに使用されます。メモリーが残らない場合、オフヒープ・キャッシュは使用されません。

オフヒープ・キャッシュの(間接的な)構成に使用するパラメータについて次で説明します。

  • systemPercent – ストレージ・ノードで使用可能なメモリーのパーセンテージを定義します。これからヒープ要件を除いた後のメモリーをオペレーティング・システムが使用できます。デフォルトではこの値は10%です。この値を10%を超え、100%未満の数に構成すると、オフヒープ・キャッシュ用のメモリーが残る可能性があります(ストレージ・ノードのメモリーとこのパラメータで選択する値によって異なります)。残りのメモリーがオフヒープ・キャッシュで使用できる場合は、オフヒープ・キャッシュが有効になります。

    ほとんどの本番システムでは、オフヒープ・キャッシュを使用するのであれば、デフォルト値の10%にすれば十分です。

  • rnHeapMaxMB – Javaヒープで使用可能な最大メモリー容量です。(ヒープはインメモリー・キャッシュが含まれるところです。)ヒープのサイズはこの値よりも小さくなります。または、次のようにrnHeapPercentパラメータ値を使用した結果のサイズになります。 
    <b>total SN memory</b> * rnHeapPercent = Heap Size
    rnHeapPercentのデフォルトのサイズは68%です。つまり、ストレージ・ノードのメモリーが32GBの場合、ヒープ・サイズは32 * 0.68 = 21.76GBになります。ただし、rnHeapMaxMBを20,480 (20 * 1024)に設定すると、ヒープ・サイズは20GBになります。

    ヒープ・サイズはインメモリー・キャッシュ・サイズと同じではないことに注意してください。インメモリー・キャッシュ・サイズはヒープ・サイズのパーセンテージとして表されます。デフォルトではこれは70%です(rnCachePercentパラメータを使用して構成可能)。したがって、ヒープ・サイズが21.76GBの場合、インメモリー・キャッシュ・サイズは15.23GB (21.76 * 0.7)になります。

    注意:

    ここで説明するパラメータに指定された値や、ヒープで使用可能な実際のメモリーにかかわらず、ヒープ・サイズは最大32GBに制限されます。
  • jvmOverheadPercent – JVMオーバーヘッド(Javaヒープ外)で使用可能なJavaヒープのパーセンテージを定義します。デフォルトでは、この値は25%で、ヒープおよびJVMオーバーヘッドがストレージ・ノード・メモリーの85% (68 + 68 * 0.25)を消費することになります。
たとえば、ストレージ・ノードのメモリーが80GBで、レプリケーション・ノードが1つのみの場合、デフォルトでは次のようになります。
  • ヒープ・サイズは32GBです(80 * .68 = 54.4ですが、これは最大サイズ32GBを超えているため)。
  • インメモリー・キャッシュ・サイズは22.4GB (32 * 0.7)です。
  • JVMオーバーヘッドのメモリー・サイズは8GB (32 * 0.25)です。
  • システム・メモリー・サイズは8GB (80 * 0.1)です。
  • オフヒープ・キャッシュ・サイズ32GB。これは、ヒープ、JVMオーバーヘッドおよびシステムの要件が満たされた後で残ったメモリー容量です。

図E-1 オフヒープ・キャッシュを使用したSNメモリー

オフヒープ・キャッシュを使用したSN 80GBメモリー

オフヒープ・キャッシュをなくす場合は、システム・メモリーを100%に設定します。ストア内の各ストレージ・ノードでこのようにします。次のコマンドを使用します。

  • ストアがデプロイされていない場合:

    kv-> change-policy -params systemPercent=100

  • ストアがデプロイされている場合:

    kv-> plan change-parameters -service sn1 -wait -params systemPercent=100

注意:

レプリケーション・ノード(RN)はデフォルトでは再起動されません。次のコマンドを使用して、RN (複数存在する場合はすべて)を再起動する必要があります。 
kv-> plan stop-service -all-rns -wait;
Executed plan 7, waiting for completion...
Plan 7 ended successfully
kv-> plan start-service -all-rns -wait;
Executed plan 8, waiting for completion...
Plan 8 ended successfully

結果は次のとおりです。

  • ヒープ・サイズは32GB、インメモリー・キャッシュ・サイズは22.4GB、JVMオーバーヘッドのメモリー・サイズは8GBになります。デフォルト構成から変更されていません。
  • システム・メモリーは40GBです。システム・メモリーは、ヒープとJVMオーバーヘッドを差し引いた残りの100%です。つまり、80GB (使用可能な合計容量) - 32GB (ヒープ・サイズ) - 8GB (JVMオーバーヘッド) = 40GBがオペレーティング・システムおよびファイル・システム・キャッシュ用になります。

図E-2 オフヒープ・キャッシュを使用しないSNメモリー

オフヒープ・キャッシュを使用しないSN 80GBメモリー