データノードのすべてのメモリー割り当ては、ノードの起動時に実行されます。 これにより、スワップメモリーを使用せずにデータノードを安定した方法で実行できるため、NDB を待機時間に依存する (リアルタイム) アプリケーションに使用できます。 データノードの起動時には、次のタイプのメモリーが割り当てられます:

ほとんどのデータノードのメモリーを規制する NDB メモリーマネージャーは、次のメモリーリソースを処理します:

これらの各リソースは、予約済メモリー領域と最大メモリー領域を使用して設定されます。 予約済メモリー領域は、予約されているリソースでのみ使用でき、他のリソースと共有することはできません。特定のリソースは、そのリソースに許可されている最大メモリーを超えることはできません。 最大メモリーがないリソースは、メモリーマネージャのすべての共有メモリーを使用するように拡張できます。

これらのリソースのグローバル共有メモリーのサイズは、SharedGlobalMemory 構成パラメータによって制御されます (デフォルト) : 128 MB).

データメモリーは常に予約され、共有メモリーからメモリーを取得することはありません。 これは、最大 16384 GB の DataMemory 構成パラメータを使用して制御されます。 DataMemory では、ハッシュインデックス (行当たり約 15 バイト)、順序付けされたインデックス (インデックス当たり 10-12 バイト) および行ヘッダー (行当たり 16-32 バイト) を含むレコードが格納されます。

redo ログバッファも予約済メモリーのみを使用します。これは、LDM スレッドごとの redo ログバッファのサイズを設定する RedoBuffer 構成パラメータによって制御されます。 つまり、実際に使用されるメモリー量は、このパラメータの値にデータノード内の LDM スレッドの数を乗算した値になります。

ジョブバッファは予約済メモリーのみを使用します。このメモリーのサイズは、様々なタイプのスレッド数に基づいて NDB によって計算されます。

送信バッファーには予約された部分がありますが、共有グローバルメモリーの 25% を追加で割り当てることもできます。 送信バッファーの予約サイズは、次の 2 つの手順で計算されます:

つまり、TotalSendBufferMemory が設定されている場合、送信バッファサイズは TotalSendBufferMemory + ExtraSendBufferMemory です。それ以外の場合、送信バッファのサイズは ([number of node connections] * SendBufferMemory) + ExtraSendBufferMemory と等しくなります。

ディスクデータレコードのページキャッシュは予約済リソースのみを使用します。このリソースのサイズは、DiskPageBufferMemory 構成パラメータ (デフォルトは 64 MB) によって制御されます。 32 KB のディスクページエントリのメモリーも割り当てられます。これらの数は、DiskPageBufferEntries 構成パラメータ (デフォルトは 10) によって決まります。

トランザクションメモリーには、NDB によって計算される予約部分があるか、NDB 8.0.19 で導入された TransactionMemory 構成パラメータを使用して明示的に設定されています (以前のリリースでは、この値は常に NDB によって計算されていました)。トランザクションメモリーでは、無制限の量の共有グローバルメモリーを使用することもできます。 トランザクションメモリーは、トランザクション、スキャン、ロック、スキャンバッファおよびトリガー操作を処理するすべての操作リソースに使用されます。 また、次のコミットによってデータメモリーに書き込まれる前に、テーブルの行も更新時に保持されます。

NDB 8.0.16 以前では、操作レコードは、サイズが多数の構成パラメータによって制御されていた専用リソースを使用していました。 NDB 8.0.17 以降、これらはすべて共通トランザクションメモリーリソースから割り当てられ、グローバル共有メモリーのリソースを使用することもできます。 NDB 8.0.19 以降では、このリソースのサイズは単一の TransactionMemory 構成パラメータを使用して制御できます。

undo ログバッファの予約済メモリーは、InitialLogFileGroup 構成パラメータを使用して設定できます。 undo ログバッファが CREATE LOGFILE GROUP SQL ステートメントの一部として作成された場合、メモリーはトランザクションメモリーから取得されます。

ディスクデータリソースのメタデータに関連する多くのリソースには予約された部分もなく、共有グローバルメモリーのみが使用されます。 したがって、共有グローバル共有メモリーは、送信バッファ、トランザクションメモリー間で共有されます。 ディスクデータのメタデータ。

TransactionMemory が設定されていない場合、次のパラメータに基づいて計算されます:

TransactionMemory が明示的に設定されている場合、リストされている構成パラメータはメモリーサイズの計算に使用されません。 また、パラメータ MaxNoOfConcurrentIndexOperations, MaxNoOfFiredTriggers, MaxNoOfLocalOperations および MaxNoOfLocalScans は TransactionMemory と互換性がなく、同時に設定することはできません。TransactionMemory が設定され、これら 4 つのパラメータのいずれかが config.ini 構成ファイルにも設定されている場合、管理サーバーは起動できません。 これらの 4 つのパラメータは NDB 8.0.19 で非推奨になりました。MySQL NDB Cluster の将来のリリースから削除される予定です。

トランザクションメモリーリソースに多数のメモリープールが含まれています。 各メモリープールはオブジェクトタイプを表し、オブジェクトのセットを含みます。各プールには、起動時にプールに割り当てられた予約部分が含まれます。この予約済メモリーは共有グローバルメモリーに戻されません。 予約済レコードは、高速取得のための単一レベルのみを持つデータ構造を使用して検出されます。つまり、各プール内の多数のレコードを予約する必要があります。 各プール内の予約済レコードの数は、パフォーマンスおよび予約済メモリーの割当てにある程度影響しますが、通常、予約済サイズを明示的に設定するには、非常に高度なユースケースでのみ必要です。

プールの予約部分のサイズは、次の構成パラメータを設定することで制御できます:

前述のパラメータが設定されていない場合、予約済の設定はトランザクションメモリーの 25% です。 予約レコードの数はデータノードごとです。これらのレコードは、各ノード上のそれらを処理するスレッド (LDM および TC スレッド) 間で分割されます。 ほとんどの場合、TransactionMemory のみを設定し、プール内のレコード数をその値で制御できるようにするだけで十分です。

MaxNoOfConcurrentScans は、各 TC スレッドでアクティブにできる同時スキャンの数を制限します。 これは、クラスタの過負荷から保護するために重要です。

MaxNoOfConcurrentOperations では、トランザクションの更新時に一度にアクティブにできる操作の数が制限されます。 (単純読取りは、このパラメータの影響を受けません。) この数を制限する必要があるのは、ノード障害処理用にメモリーを事前に割り当てる必要があり、ノード障害が発生した場合に 1 つの TC スレッドでアクティブな操作の最大数を処理するためにリソースを使用できる必要があるためです。 すべてのノードで MaxNoOfConcurrentOperations を同じ数に設定する必要があります (これは、config.ini グローバル構成ファイルの[ndbd default]セクションで値を一度設定することで最も簡単に実行できます)。 ローリング再起動を使用して値を増やすことはできますが (セクション23.5.5「NDB Cluster のローリング再起動の実行」 を参照)、ローリング再起動中にノード障害が発生する可能性があるため、この方法で値を減らすことは安全とはみなされません。

NDB Cluster 内の単一トランザクションのサイズは、MaxDMLOperationsPerTransaction パラメータを使用して制限できます。 これが設定されていない場合、TC スレッド当たりの同時操作の合計数が制限されるため、あるトランザクションのサイズは MaxNoOfConcurrentOperations によって制限されます。

スキーマメモリーサイズは、次の一連の構成パラメータによって制御されます:

各テーブルおよび各パーティション (およびそのフラグメントレプリカ) のパーティション数はスキーマメモリーで表す必要があるため、ノードの数と LDM スレッドの数もスキーマメモリーのサイズに大きく影響します。

また、他の多数のレコードが起動時に割り当てられます。 これらは比較的小さいです。 各スレッドの各ブロックには、メモリーを使用するブロックオブジェクトが含まれます。 このメモリーサイズは、通常、ほかのデータノードメモリー構造に比べて非常に小さくなります。