database_memory - データベース共有メモリー・サイズの構成パラメーター

database_memory 構成パラメーターは、データベース・メモリー・セットのサイズを指定します。 データベース・メモリー・サイズは、有効なインスタンス・メモリー制限に影響を与えます。 この設定は、構成可能なメモリー・プール (バッファー・プール、データベース・ヒープ、ロックリスト、ユーティリティー・ヒープ、パッケージ・キャッシュ、カタログ・キャッシュ、共有ソート・ヒープ、および追加の最小オーバーフロー域として 5%) に十分対応できる大きさでなければなりません。
構成タイプ
データベース
適用
  • ローカルとリモート・クライアントを持つデータベース・サーバー
  • ローカル・クライアントを持つデータベース・サーバー
  • ローカル・クライアントおよびリモート・クライアントを持つパーティション・データベース・サーバー
パラメーター・タイプ
  • オンラインで構成可能 (データベース接続が必要)
    注: データベース接続が必要です。 固定したメモリーやラージ・ページ構成の場合は、動的変更は制限されます。
  • Db2® pureScale® 環境およびパーティション・データベース環境のメンバーにより構成可能
デフォルト [範囲]
AUTOMATIC [AUTOMATICCOMPUTED0 - 4 294 967 295]
単位
ページ (4 KB)
割り振りまたはコミットのタイミング
Linux および UNIX オペレーティング・システムの場合
データベースをアクティブ化したときに、初期サイズが割り振られます。 必要に応じて、追加のメモリーが割り振られます。
Windows オペレーティング・システムの場合
必要に応じてメモリーが割り振られます。
データベースをアクティブ化したときに、バッファー・プール、ロックリスト、および基本インフラストラクチャー用のメモリーがコミットされます。 必要に応じて、追加のメモリーがコミットされます。
解放されるタイミング
データベースを非アクティブ化したときに、すべてのデータベース・メモリーが解放されます。 セルフチューニング・メモリー・マネージャー (STMM) は、データベース・メモリー・サイズを削減するときに、メモリーを解放してオペレーティング・システムに戻します。 メモリーの追加の解放は、db_mem_thresh 構成パラメーターに従属しています。

UNIX オペレーティング・システムでは、データベース活動化時に初期データベース・メモリー・サイズを割り振った後、 Db2 は動的要件をサポートするために必要に応じて追加メモリーを割り振ります。 追加のメモリー割り振りは、固定サイズの制限に従属します。 データベース・メモリーはすべて共有メモリーとして割り振られ、データベースを非アクティブ化するまで保持されます。 割り振られる共有メモリーの合計は、仮想メモリー使用量にのみ影響を与えます。 実メモリーによってこれをバッキングする必要はありませんが、一部のオペレーティング・システムではスワップまたはページング・スペースによって仮想メモリーをバッキングする必要があります。 Windows オペレーティング・システムでは、データベース・メモリーは必要に応じて専用メモリーとして割り振られ、固定サイズの制限に従属します。 割り振られた部分が使用されなくなると、動的に解放されるか、再利用するために保持されます。 未解決のメモリー割り振りはすべて、データベースが非アクティブ化されたときに解放されます。 オペレーティング・システム・サポートについて詳しくは、「 オペレーティング・システム・サポート 」セクションを参照してください。

コミット済みのメモリーとは、オペレーティング・システムでバッキングされるメモリーのことです。 固定されたメモリー (ラージ・ページ構成を含む) を除き、割り振られたメモリーはメモリー・プールでの必要に応じてコミットされます。 コミット済みのメモリーがメモリー・プールにとって必要なくなった場合は、キャッシュに入れられてパフォーマンスが改善されるか、解放 (コミット解除) されてオペレーティング・システムに戻されます。 実行されるアクションは、db_mem_thresh 構成パラメーターに従属しています。 STMM などによって database_memory のサイズが削減されるときにも、必要に応じてメモリーが解放されたりコミット解除されたりします。 コミット済みのメモリーはすべて、データベースが非アクティブ化されたときに解放されます。

データベース・メモリー・サイズは、インスタンス・メモリーの使用量に影響を与えます。 データベース・メモリー・オーバーフロー域は、データベース・メモリー・コンシューマー用にキャッシュに入れられるインスタンス・メモリーと等しくなります。 必要に応じて、データベース・メモリー・オーバーフローを、データベース・インスタンスによって使用される他のメモリー域の要件に適合するように、動的に減らすことができます。 この処理は、インスタンス・メモリーの制限が有効である場合に、自動的に行われます。

データベース・メモリー・サイズから、基礎となるメモリー・プールの構成済みのサイズが予約されます。 残りのデータベース・メモリーは、オーバーフロー・メモリーと見なされます。 通常、メモリー・プールは、予約されていないメモリーとも呼ばれる、使用可能なオーバーフローを使用できます。

セルフチューニング・メモリー・マネージャー (STMM) は、主なメモリー域を自動的に構成するために使用できるフィーチャーです。 STMM で、データベース・メモリー全体のサイズや、データベース・メモリー内の以下の区域をチューニングできるようにすることができます。
  • バッファー・プール
  • ロックリスト
  • 共有ソート・ヒープ (SHEAPTHRES が 0 の場合)
  • パッケージ・キャッシュ
オーバーフロー域のサイズは、データベース・メモリーのサイズに依存しています。 大きなデータベース・メモリー・サイズでは必要なオーバーフローは少なく、小さいサイズではより多くのオーバーフロー (最大 10%) が必要になります。 オーバーフローの量は、データベースの活動化時に計算されるほか、STMM オーバーフロー・チューニングの一環として継続的に計算されます。
表 1. データベース・メモリー・サイズとオーバーフローの比較
データベース・メモリーのサイズ オーバーフロー・ターゲット
64 GB 以下 10%
64 - 96 GB 9%
96 - 156 GB 8%
156 - 266 GB 7%
266 - 493 GB 6%
493 GB 以上 5%

database_memory に割り当てることができる値の動作は以下のとおりです。

自動 (Automatic)
database_memoryAUTOMATIC に設定すると、基礎となる構成要件に基づいて初期データベース・メモリー・サイズが計算されます。 以下のものが含まれます。
  • バッファー・プール
  • データベース・ヒープ
  • ロックリスト
  • ユーティリティー・ヒープ
  • パッケージ・キャッシュ
  • カタログ・キャッシュ
  • 使用可能な場合は、共有ソート・ヒープ
  • オーバーフロー域

AUTOMATIC に設定すると、オーバーフローに指定された要件を超える不測の要件がある場合に、データベース・メモリーを初期サイズより大きくすることができます。 個々のメモリー・プールに手動または STMM で動的構成変更を加えても、対応する量でデータベース・メモリー・サイズを調整できます。

STMM が使用可能な場合 ( SELF_TUNING_MEM の値が ONの場合)、STMM はデータベース・メモリー全体のサイズを制御します。 STMM は、オーバーフローなどの基礎となる構成要件と、追加の使用可能メモリーを獲得することによるパフォーマンス上の利点を考慮します。 instance_memory の設定によっては、STMM はシステム・メモリーやインスタンス・メモリーが不足しないようにデータベース・メモリーをチューニングします。 DB2_MEM_TUNING_RANGE 変数を使用して制御できるメモリーのパーセンテージは、揮発性の要件を満たすために使用可能なままになります。 データベースをアクティブ化したときに、システム・メモリーかインスタンス・メモリーが不足していて、開始構成をサポートできない場合、STMM によってチューニングされたメモリー域は、既存のメモリー制約に適合するように減らされます。 このアクションは、適用されている最小サイズによって変わります。

固定値
特定の値を database_memory 構成パラメーターに割り当てることができます。 しかし、最小構成要件をサポートできる大きさの値を指定する必要があります。 以下のものが含まれます。
  • バッファー・プール
  • データベース・ヒープ
  • ロックリスト
  • ユーティリティー・ヒープ
  • パッケージ・キャッシュ
  • カタログ・キャッシュ
  • 使用可能な場合は、共有ソート・ヒープ
  • 5% の最小オーバーフロー域

割り当てられた値が小さすぎると、その値より大きい、構成をサポートするために必要な最小サイズが割り振られます。 固定の設定やこの最小サイズより大きなデータベース・メモリーを割り振ることはできません。 しかし、引き続きデータベース・メモリー設定を動的に大きくしたり AUTOMATIC に変更したりできます。 メモリー・プールを大きくする動的構成変更は、十分なオーバーフローが使用可能である場合のみ正常に実行されます。

STMM が使用可能な場合 ( SELF_TUNING_MEM の値が ONの場合)、基礎となるメモリー・プールとオーバーフローのみが調整されます。 データベースをアクティブ化するときに、固定の設定が存在し、この値が小さすぎて現行の構成をサポートできない場合、STMM によってチューニングされる個々の領域は、既存のメモリー制約に適合するように縮小されます。 このアクションは、適用されている最小サイズによって変わります。 database_memory の固定構成の半分以上を、STMM によるチューニング用に残しておくことをお勧めします。 例えば、バッファー・プール域のサイズを手動で設定する場合は、バッファー・プールの消費量が database_memory の固定設定の半分を超えないようにしてください。 半分を超えると、STMM のチューニング機能が制約を受け、パフォーマンスが最適でなくなったり、メモリー・リソースの制約に関連する症状が発生したりする可能性があります。

COMPUTED
COMPUTED はレガシー設定です。 STMM が使用可能になっていない場合は、この動作は AUTOMATIC と同様です。 STMM を使用可能にした場合は、COMPUTED の動作は固定値の動作と同様です。

オペレーティング・システムのサポート

表 2. オペレーティング・システムのサポート
オペレーティング・システム 使用可能なサポート
AIX デフォルトでは、パフォーマンス上の利点があるミディアム (64K) ページを使用します。 AIX は固定したメモリーやラージ/ヒュージ (16MB/16GB) ページをサポートします。1
HP-UX 割り振られた共有メモリーは、仮想スワップでバッキングされる必要があります。 HP-UX は固定したメモリーをサポートします。1
Linux 割り振られた共有メモリーは、仮想共有メモリー制限 (shmall) にカウントされます。 Linux は固定したメモリーやラージ (2MB) ページをサポートします。1
Solaris 割り振られた共有メモリーは、仮想スワップでバッキングされる必要があり、仮想メモリー制限に影響を与えます。 Solaris は固定した ISM メモリーやラージ・ページをサポートします。2
Windows ラージ (2MB) ページをサポートします。1
注:
  1. メモリー・ピン (DB2_PINNED_BP) およびラージ/ヒュージ・ページ (DB2_LARGE_PAGE_MEM) を使用すると、メモリーを動的に解放する機能が制限されます。 このタイプの環境では、STMM が実行するチューニングは限定され、データベース・メモリー全体のサイズの調整は試行されません。 これらの構成下で STMM を使用する際には database_memory の固定値を構成することをお勧めします。この場合、STMM は一貫性のあるデータベース・メモリー・サイズ変更を最大限に活用できます。
  2. Solaris オペレーティング・システムで database_memoryAUTOMATIC に設定する場合、データベース・マネージャーはデータベース共有メモリーにページング可能メモリーを使用します。 この場合、データベース・メモリー構成の調整は完全に動的になり、STMM はデータベース・メモリー全体のサイズをチューニングします。 SPARC アーキテクチャーでは、データベース・マネージャーは、使用可能な場合、64 KB のメモリー・ページの使用を試みます。 使用可能でない場合、8 KB のメモリー・ページが使用されます。 x64 アーキテクチャーでは、データベース・マネージャーは 4KB のメモリー・ページを使用します。 データベース・メモリーの固定値か COMPUTED のオプションを使用する際には、ISM (固定) メモリーが割り振られます。 この場合、Solaris は該当する最大のページ・サイズを選択するので、パフォーマンスが改善される可能性があります。 しかし、動的データベース・メモリー構成変更は制限され、STMM によるデータベース・メモリー全体のサイズのチューニングは試行されません。 Solaris オペレーティング・システムでは、AUTOMATIC オプションと他の database_memory オプションとの間の変更を動的に実行できません。

モニター

データベース・メモリー・セットは、 MON_GET_MEMORY_SET および MON_GET_MEMORY_POOL ルーチンを介してモニターできます。 例えば、下記のコマンドを行ったとします。
db2 "select member, substr(db_name,1,10)as db_name, substr(memory_set_type,1,10) as set_type, 
memory_set_size, memory_set_committed, memory_set_used, memory_set_used_hwm 
from table(mon_get_memory_set('DATABASE','',-1))" 
以下の情報が戻されます。
MEMBER DB_NAME    SET_TYPE   MEMORY_SET_SIZE      MEMORY_SET_COMMITTED MEMORY_SET_USED      MEMORY_SET_USED_HWM 
------ ---------- ---------- -------------------- -------------------- -------------------- -------------------- 
     0 SAMPLE     DATABASE                 154927                68616                67829                68616 
     0 TEST       DATABASE                 238092               123404               123404               123404 

  2 record(s) selected. 

この場合、データベース・メモリー・セットは instance_memory (MEMORY_SET_SIZE) の 154927KB とシステム・メモリー (MEMORY_SET_COMMITTED) の 68616KB を使用しており、そのうち 67829KB (MEMORY_SET_USED) がメモリー・プールに割り当てられています。

以下のように db2pd ユーティリティーを使用してデータベース・メモリーをモニターすることもできます。
db2pd -db  <database_name> -memsets -mempools, db2pd -dbptnmem