翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon DocumentDB のガベージコレクション
Amazon DocumentDB は、更新オペレーションごとにドキュメントエントリとインデックスエントリの新しいバージョンを作成するマルチバージョン同時実行制御 (MVCC) データベースアーキテクチャを実装します。このアーキテクチャは、読み取りクエリがロックなしでバージョニングされたドキュメントを使用できるようにすることで、読み取り分離を提供します。
Amazon DocumentDB のガベージコレクションについて
ガベージコレクション (GC) は、Amazon DocumentDB で最適なシステムパフォーマンスと可用性を維持する自動化されたバックグラウンドプロセスです。データを上書きする従来のデータベースとは異なり、Amazon DocumentDB の MVCC アーキテクチャは、更新オペレーションごとに新しいバージョンのドキュメントとインデックスエントリを作成します。新しいドキュメントバージョンになるすべての書き込みオペレーションは、有限カウンターから一意の MVCC ID を消費するため、効率的なクリーンアップが不可欠です。これらの古いバージョンは時間の経過とともに蓄積されるため、パフォーマンスの低下を防ぐためにクリーンアップする必要があります。
ガベージコレクションの関数
ガベージコレクターには 3 つの重要な機能があります。
ストレージスペースの再利用 — アクティブなクエリで不要になった古いドキュメントバージョンとインデックスバージョンを削除し、将来の書き込みオペレーションのためのスペースを解放します。
MVCC ID オーバーフローを防止 — MVCC ID の有限カウンターを管理することで、MVCC IDs。この管理を行わないと、カウンターは最終的に制限に達し、IDsします。
クエリパフォーマンスを維持 — そうしないとクエリ処理が蓄積および遅くなるデッドドキュメントバージョンを排除することで、最適なクエリパフォーマンスを維持します。
ガベージコレクションプロセス
GC プロセスはコレクションごとに動作し、異なるコレクションで複数のプロセスを同時に実行できます。このプロセスは 4 つのシーケンシャルフェーズで構成されます。
識別 — システムは、アクティブなトランザクションまたはクエリによって参照されなくなったドキュメントバージョンとインデックスバージョンを識別します。
メモリのロード — 古いドキュメントとインデックスエントリが存在しない場合、メモリにロードされます。
削除 — 古いバージョンは、ストレージ容量を再利用するために完全に削除されます。
MVCC ID リサイクル — システムは、新しいオペレーションのために削除されたバージョンの MVCC IDs をリサイクルします。
ガベージコレクションが古いドキュメントバージョンの処理を完了すると、システムから最も古い MVCC IDsが削除されます。このクリーンアップは、MVCC ID をリサイクルして MVCC IDs のオーバーフローを防止し、クラスター全体の新しい書き込みオペレーションで使用できるようにするために不可欠です。このリサイクルプロセスがないと、システムは最終的に有限の MVCC ID カウンターを使い果たし、読み取り専用状態になります。
ガベージコレクションのスケジューリング
ガベージコレクションは、定期的にバックグラウンドで自動的に実行されます。タイミングと頻度は、システム負荷、使用可能なリソース、書き込みボリューム、MVCC ID 消費レベルに基づいて動的に調整されます。書き込みアクティビティが多い場合、GC プロセスはより頻繁に実行され、ドキュメントバージョン数の増加を管理します。
ガベージコレクションのモニタリング
クラスターレベルのメトリクス
AvailableMVCCIds
場所 — Amazon CloudWatch
説明 — ゼロに達する前に使用可能な残りの書き込みオペレーションの数を示すカウンター。このカウンターがゼロに達すると、IDs が再利用されてリサイクルされるまで、クラスターは読み取り専用モードになります。カウンターは書き込みオペレーションごとに減少し、ガベージコレクションが古い MVCC IDs。
推奨事項 — 値が 13 億を下回るとアラームを設定します。この早期警告により、後で説明する推奨手順を実行できます。
LongestRunningGCProcess
場所 — Amazon CloudWatch
説明 — 最も長いアクティブなガベージコレクションプロセスの秒単位の所要時間。1 分ごとに更新し、1 分以内に完了したプロセスを除き、アクティブなオペレーションのみを追跡します。
推奨事項 —
コレクションレベルのメトリクス
MVCCIDStats: MvccIdAgeScale
Location — Database collStats コマンド
説明 — 0～1 のスケールで MVCC ID の経過時間を測定します。1 は、クラスターが読み取り専用状態になる前の最大経過時間を示します。このメトリクスを と一緒に使用
AvailableMVCCIdsして、クラスターを古くしている最も古い MVCC IDs を含むコレクションを識別します。推奨事項 — コレクションごとに 0.3 未満の値を維持します。
GCRuntimeStats
Location — Database collStats コマンド
説明 — 合計実行数、平均期間、最大期間など、ガベージコレクションメトリクスの 2 か月の履歴を提供します。意味のある統計を確保するために 5 分以上続くガベージコレクションオペレーションのみが含まれます。
UnusedStorageSize (コレクションレベル）
Location — Database collStats コマンド
説明 — サンプル統計に基づいて、コレクション内の未使用のストレージ領域を推定します。削除されたドキュメントと空のセグメントからのスペースが含まれます。
インデックスレベルのメトリクス
UnusedStorageSize (インデックスレベル）
Location — データベース indexStats コマンド
説明 — サンプル統計に基づいて、インデックス内の未使用のストレージ領域を推定します。これには、古いインデックスエントリと空のセグメントからのスペースが含まれます。
推奨事項 —
reIndexコマンドを使用してダウンタイムなしでインデックスを再構築し、未使用のスペースを再利用します。詳細については、「インデックスの管理」を参照してください。
collStats 出力例
{
"ns": "xid_consumption_test_db.xid_test_collection",
"MVCCIdStats": {
"MVCCIdScale": 0.03
},
"gcRuntimeStats": {
"numRuns": 1,
"historicalAvgRuntime": 3295,
"historicalMaxRuntime": 3295,
"lastRuntime": 3295,
"lastRuntimeStart": ISODate("2025-06-24T08:47:14Z")
},
"collScans": 14,
"count": 30000000,
"size": 1320000000,
"avgObjSize": 44,
"storageSize": 6461497344,
"capped": false,
"nindexes": 2,
"totalIndexSize": 9649553408,
"indexSizes": {
"_id_": 1910661120,
"c_1": 7738892288
},
"unusedStorageSize": {
"unusedBytes": 4201881600,
"unusedPercent": 65.05
},
"cacheStats": {
"collBlksHit": 171659016,
"collBlksRead": 754061,
"collHitRatio": 99.5627,
"idxBlksHit": 692563636,
"idxBlksRead": 1177921,
"idxHitRatio": 99.8303
},
"idxScans": 41823984,
"opCounter": {
"numDocsIns": 0,
"numDocsUpd": 20911992,
"numDocsDel": 0
},
"lastReset": "2025-06-24 05:57:08.219711+00",
"ok": 1,
"operationTime": Timestamp(1750968826, 1)
}よくある質問
トピック
ガベージコレクションが効率的に機能していないかどうかを確認するにはどうすればよいですか？
非効率的なガベージコレクションを示す次の警告サインをモニタリングします。
過剰なコレクションの肥大化 — 特に大きなインデックスでは、大量の書き込みや一括削除中に
UnusedStorageSizeメトリクスが着実に増加します。クエリレイテンシーの低下 — デッドドキュメントの蓄積によるクエリレイテンシーの増加
GC 期間の延長 — ガベージコレクションオペレーションには、 の履歴平均よりも時間がかかります
GCRuntimeStatsGC 処理の向上 — ガベージコレクターがシステム需要に追いついていない
LongestRunningGCProcessことを示す高い
ガベージコレクションはデータベースのパフォーマンスに影響しますか？
通常の条件下では、ガベージコレクションのパフォーマンスへの影響は最小限です。ただし、ガベージコレクションが遅れると、以下が発生する可能性があります。
は、蓄積されたデッドドキュメントのストレージコストを増加させました。
古いインデックスエントリによるクエリパフォーマンスの低下。
MVCC IDsが枯渇した場合の一時的な読み取り専用モード。
特に小規模なインスタンスでは、集中的な収集の実行中のリソース使用量が増加します。
ガベージコレクションを手動でトリガーできますか？
いいえ。Amazon DocumentDB のガベージコレクションを手動でトリガーすることはできません。システムは、内部メンテナンスオペレーションの一部としてガベージコレクションを自動的に管理します。
運用上のベストプラクティスとして設定すべきアラームは何ですか？
Amazon DocumentDB システムの最適なパフォーマンスを確保するために、クラスターレベルとコレクションレベルの両方でモニタリングを設定することをお勧めします。
クラスターレベルのモニタリングの場合
まず、しきい値が 13 億のAvailableMVCCIdメトリクスの CloudWatch アラームを作成します。これにより、メトリクスが 0 に達する前にアクションを実行するのに十分な時間が与えられます。ゼロに達すると、クラスターは読み取り専用モードになります。このメトリクスは、特定の使用パターンに基づいて変動する場合があることに注意してください。一部のお客様は、ガベージコレクションが作業を完了すると、13 億を下回ってから 15 億を回復します。
CloudWatch を使用してLongestRunningGCProcessメトリクスをモニタリングすることも重要です。このメトリクスは、 とともにGCRuntimeStats、システム全体でのガベージコレクションのパフォーマンスを理解するのに役立ちます。
コレクションレベルのモニタリングの場合
2 つの主要なメトリクスに焦点を当てます。まず、各コレクションMvccIdAgeScaleの値を確認することをお勧めします。値を大きくすると、MVCC IDs古くなり、注意が必要な場合があります。次に、モニタリングGCRuntimeStatsして、異常に長い時間がかかっている、または数日間にわたって拡張されているガベージコレクションプロセスを特定します。書き込み操作が頻繁なコレクションでは、ガベージコレクターの作業が増えるため、特に注意が必要です。ガベージコレクションがワークロードに遅れないように、書き込みアクティビティが多いコレクションでは、これらのメトリクスをより頻繁にチェックすることをお勧めします。
これらのモニタリングレコメンデーションが出発点となることに注意してください。システムの動作に慣れたら、特定の使用パターンと要件に合わせてこれらのしきい値を調整することをお勧めします。
が 13 億をAvailableMVCCId下回った場合はどうすればよいですか？
AvailableMVCCId メトリクスが 13 億を下回った場合は、クラスターが読み取り専用モードにならないようにすぐにアクションを実行することをお勧めします。まずインスタンスサイズをスケールアップして、ガベージコレクターにより多くのコンピューティングリソースを提供することをお勧めします。これにより、アプリケーションは通常のオペレーションを継続しながら、ガベージコレクターに追いつくために必要な追加のパワーを与えることができます。
単独でスケールアップしても状況が改善しない場合は、書き込みオペレーションの削減を検討することをお勧めします。MvccIdAgeScale メトリクスを使用して、注意が必要な古い MVCC IDs を含む特定のコレクションを特定します。これらのコレクションを特定したら、ガベージコレクションが追いつくことができるように、それらのコレクションへの書き込みオペレーションを一時的に減らす必要がある場合があります。復旧期間中は、 AvailableMVCCIdメトリクスを注意深くモニタリングして、アクションが望ましい効果を持っていることを確認することをお勧めします。AvailableMVCCId 値が 15 億以上に戻ると、クラスターは正常と見なされます。
これらのステップは、システムが重大な状態になる前に回復するための予防策であることに注意してください。メトリクスが 13 億を下回った後にアクションを実行するほど、書き込みオペレーションへの影響を回避する可能性が高くなります。
