自己管理型配置のプロダクション ノート
項目一覧
このページでは、特に本番環境で実行する場合の MongoDB に影響するシステム構成について詳しく説明します。
警告
MMAPv1 削除
MongoDB 4.2では非推奨の MMAPv 1 storage engine が削除されます。 MMAPv 1ストレージ エンジンの配置を WiredTiger ストレージ エンジンに変更するには、次の手順を参照してください。
注意
MongoDB Atlas は、クラウドでホストされるサービスとしてのデータベースです。ホスト型サービスである MongoDB Cloud Manager とオンプレミス ソリューションである Ops Manager は、MongoDB インスタンスの監視、バックアップ、および自動化を提供します。ドキュメントについては、 Atlas のドキュメント、MongoDB Cloud Manager のドキュメント、および Ops Manager のドキュメント を参照してください。
MongoDB Atlas でホストされている配置を本番環境で実行する方法の詳細については、「 Atlas プロダクション ノート 」を参照してください。
プラットフォーム サポート
本番環境で実行する場合、オペレーティング システムの推奨事項については、「推奨プラットフォーム」を参照してください。
プラットフォーム サポート ノート
注意
MongoDB 4.0 では、macOS 10.12.x、10.13.x、10.14.0 の不正シャットダウン中にデータが失われる可能性があります。 この問題は macOS 10.14.1 で Apple によって修正されました。
詳細については、 WT-4018 を参照してください。
x86_64
MongoDB には、最低限、次の x86_64
マイクロアーキテクチャが必要です。
Intel
x86_64
の場合、MongoDB には次のいずれかが必要です。Sandy Bridge 以降の Core プロセッサ、または
Tiger Lake 以降の Celeron または Pentium プロセッサ。
AMD
x86_64
の場合、MongoDB には以下が必要です。Bulldozer 以降のプロセッサ。
MongoDB 5.0 以降、 mongod
、 mongos
、およびレガシーmongo
shell は、この最小マイクロアーキテクチャ要件を満たさないx86_64
プラットフォームのサポーを終了しました。
MongoDB は Red Hat Compatible Kernel(RHCK)を実行している Oracle Linux のみをサポートしています。MongoDBはUnbreakable Enterprise Kernel(UEK)をサポートしていません。
MongoDB5.0 では、 特定の Intel および AMD プロセッサ で利用可能な AVX 命令セットを使用する必要があります。
ARM64
arm64
上の MongoDB には ARMv8.2-A、またはそれ以降のマイクロアーキテクチャが必要です。
MongoDB 5.0 以降、 mongod
、 mongos
、およびレガシーmongo
shell は、この最小マイクロアーキテクチャ要件を満たさないarm64
プラットフォームのサポーを終了しました。
注意
MongoDB は、適切な CPU アーキテクチャを持たないシングルボード ハードウェア(Raspberry Pi 4)のサポートは停止しました。詳細については、「MongoDB 5.0 の互換性の変更」を参照してください。
プラットフォーム サポート マトリクス
重要
v 4.4のサポート終了
V4.4 は 2024 年 2 月 29日のサポート終了に伴い、MongoDB でサポートされなくなりました。
プラットフォーム | アーキテクチャ | エディション | 8.0 | 7.0 | 6.0 | 5.0 | 4.4 |
---|---|---|---|---|---|---|---|
Amazon Linux 2023 | x86_64 | エンタープライズ | ✓ | ✓ | |||
Amazon Linux 2023 | x86_64 | Community | ✓ | ✓ | |||
Amazon Linux V2 | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ✓ | |
Amazon Linux V2 | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | |
Debian 12 | x86_64 | エンタープライズ | ✓ | ✓ | |||
Debian 12 | x86_64 | Community | ✓ | ✓ | |||
Debian 11 | x86_64 | エンタープライズ | ✓ | ✓ | 5.0.8+ | ||
Debian 11 | x86_64 | Community | ✓ | ✓ | 5.0.8+ | ||
Debian 10 | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ||
Debian 10 | x86_64 | Community | ✓ | ✓ | ✓ | ||
Debian 9 | x86_64 | エンタープライズ | ✓ | ✓ | |||
Debian 9 | x86_64 | Community | ✓ | ✓ | |||
RHEL/Rocky/Alma/Oracle Linux 9.0+ [1] | x86_64 | エンタープライズ | ✓ | ✓ | 6.0.4+ | ||
RHEL/Rocky/Alma/Oracle Linux 9.0+ [1] | x86_64 | Community | ✓ | ✓ | 6.0.4+ | ||
RHEL/Rocky/Alma/Oracle Linux 8.0+ [1] | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ✓ | ✓ |
RHEL/Rocky/Alma/Oracle Linux 8.0+ [1] | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | ✓ |
RHEL/CentOS/Oracle Linux 7.0+ [1] | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ✓ | |
RHEL/CentOS/Oracle Linux 7.0+ [1] | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | |
RHEL/CentOS/Oracle Linux 6.2+ [1] | x86_64 | エンタープライズ | ✓ | ||||
RHEL/CentOS/Oracle Linux 6.2+ [1] | x86_64 | Community | ✓ | ||||
SLES 15 | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ✓ | ✓ |
SLES 15 | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | ✓ |
SLES 12 | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ✓ | |
SLES 12 | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | |
Ubuntu 24.04 | x86_64 | エンタープライズ | ✓ | ||||
Ubuntu 24.04 | x86_64 | Community | ✓ | ||||
Ubuntu 22.04 | x86_64 | エンタープライズ | ✓ | ✓ | 6.0.4+ | ||
Ubuntu 22.04 | x86_64 | Community | ✓ | ✓ | 6.0.4+ | ||
Ubuntu 20.04 | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ✓ | ✓ |
Ubuntu 20.04 | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | ✓ |
Ubuntu 18.04 | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ||
Ubuntu 18.04 | x86_64 | Community | ✓ | ✓ | ✓ | ||
Ubuntu 16.04 | x86_64 | エンタープライズ | ✓ | ||||
Ubuntu 16.04 | x86_64 | Community | ✓ | ||||
Windows 11 | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ||
Windows 11 | x86_64 | Community | ✓ | ✓ | ✓ | ||
Windows Server 2022 | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ||
Windows Server 2022 | x86_64 | Community | ✓ | ✓ | ✓ | ||
Windows Server 2019 | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ✓ | |
Windows Server 2019 | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | |
Windows 10 / Server 2016 | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ||
Windows 10 / Server 2016 | x86_64 | Community | ✓ | ✓ | ✓ | ||
macOS 14 | x86_64 | エンタープライズ | ✓ | ||||
macOS 14 | x86_64 | Community | ✓ | ||||
macOS 13 | x86_64 | エンタープライズ | ✓ | ✓ | |||
macOS 13 | x86_64 | Community | ✓ | ✓ | |||
macOS 12 | x86_64 | エンタープライズ | ✓ | ✓ | |||
macOS 12 | x86_64 | Community | ✓ | ✓ | |||
macOS 11 | x86_64 | エンタープライズ | ✓ | ✓ | |||
macOS 11 | x86_64 | Community | ✓ | ✓ | |||
macOS 10.15 | x86_64 | エンタープライズ | ✓ | ✓ | ✓ | ||
macOS 10.15 | x86_64 | Community | ✓ | ✓ | ✓ | ||
macOS 10.14 | x86_64 | エンタープライズ | ✓ | ✓ | |||
macOS 10.14 | x86_64 | Community | ✓ | ✓ | |||
macOS 10.13 | x86_64 | エンタープライズ | ✓ | ||||
macOS 10.13 | x86_64 | Community | ✓ | ||||
macOS 14 | arm64 | エンタープライズ | ✓ | ||||
macOS 14 | arm64 | Community | ✓ | ||||
macOS 13 | arm64 | エンタープライズ | ✓ | ✓ | |||
macOS 13 | arm64 | Community | ✓ | ✓ | |||
macOS 12 | arm64 | エンタープライズ | ✓ | ✓ | |||
macOS 12 | arm64 | Community | ✓ | ✓ | |||
macOS 11 | arm64 | エンタープライズ | ✓ | ✓ | |||
macOS 11 | arm64 | Community | ✓ | ✓ | |||
Amazon Linux 2023 | arm64 | エンタープライズ | ✓ | ✓ | |||
Amazon Linux 2023 | arm64 | Community | ✓ | ✓ | |||
Amazon Linux 2 | arm64 | エンタープライズ | ✓ | ✓ | ✓ | 4.4.4+ | |
Amazon Linux 2 | arm64 | Community | ✓ | ✓ | ✓ | 4.4.4+ | |
RHEL/CentOS/Rocky/Alma 9 | arm64 | エンタープライズ | ✓ | ✓ | ✓ | ||
RHEL/CentOS/Rocky/Alma 9 | arm64 | Community | ✓ | ✓ | ✓ | ||
RHEL/CentOS/Rocky/Alma 8 | arm64 | エンタープライズ | ✓ | ✓ | ✓ | ✓ | 4.4.4+ |
RHEL/CentOS/Rocky/Alma 8 | arm64 | Community | ✓ | ✓ | ✓ | ✓ | 4.4.4+ |
Ubuntu 24.04 | arm64 | エンタープライズ | ✓ | ||||
Ubuntu 24.04 | arm64 | Community | ✓ | ||||
Ubuntu 22.04 | arm64 | エンタープライズ | ✓ | ✓ | 6.0.4+ | ||
Ubuntu 22.04 | arm64 | Community | ✓ | ✓ | 6.0.4+ | ||
Ubuntu 20.04 | arm64 | エンタープライズ | ✓ | ✓ | ✓ | ✓ | ✓ |
Ubuntu 20.04 | arm64 | Community | ✓ | ✓ | ✓ | ✓ | ✓ |
Ubuntu 18.04 | arm64 | エンタープライズ | ✓ | ✓ | ✓ | ||
Ubuntu 18.04 | arm64 | Community | ✓ | ✓ | ✓ | ||
Ubuntu 16.04 | arm64 | エンタープライズ | ✓ | ||||
RHEL/Rocky/Alma 9 | ppc64le | エンタープライズ | ✓ | ✓ | |||
RHEL/Rocky/Alma 8 | ppc64le | エンタープライズ | ✓ | ✓ | ✓ | ✓ | ✓ |
RHEL/CentOS 7 | ppc64le | エンタープライズ | 6.0.7+ | ✓ | ✓ | ||
RHEL/Rocky/Alma 8 | s390x | エンタープライズ | ✓ | ✓ | ✓ | 5.0.9+ | |
RHEL/CentOS 7 | s390x | エンタープライズ | ✓ | ✓ | ✓ | ||
RHEL/CentOS 7 | s390x | Community | ✓ | ✓ |
[1] | (1、2、3、4、5、6、7、8) Oracle Linux では、MongoDB は Red Hat Compatible Kernel のみをサポートします。 |
[2] | MongoDB バージョン 5.0 以降は、SLES 12 サービス パック 5 に対してテストされています。MongoDB の以前のバージョンは、サービス パックなしの SLES 12 に対してテストされています。 |
推奨プラットフォーム
MongoDB はさまざまなプラットフォームをサポートしていますが、 x86_64
アーキテクチャでの運用には次のオペレーティング システムが推奨されます。
Amazon Linux
Debian
RHEL [3]
SLES
Ubuntu LTS
Windows Server
最良の結果を得るには、プラットフォームの最新バージョンを実行してください。古いバージョンを実行している場合は、そのバージョンがプロバイダーによってサポートされていることを確認してください。
[3] | RHEL バージョン 8.0 以降向けにリリースされた MongoDB オンプレミス製品は、Rocky Linux バージョン 8.0以降、AlmaLinux バージョン 8.0以降と互換性があります。ただし、これらのディストリビューションが完全な RHEL 互換性を提供する義務を果たすことが前提となります。 |
最新の安定パッケージを使用する
最新の安定版リリースを使用していることを確認してください。
すべての MongoDB のリリースは、MongoDB ダウンロード センターページで入手できます。パッケージ マネージャーを使用してインストールする場合でも、MongoDB ダウンロード センターは、現在の安定したリリースを確認するのに適した場所です。
その他の MongoDB 製品については、MongoDB ダウンロード センター ページまたはそれぞれのドキュメントを参照してください。
MongoDB dbPath
dbPath
ディレクトリ内のファイルは、構成されたストレージ エンジンに対応している必要があります。dbPath
--storageEngine
に で指定されたストレージ エンジン以外のストレージ エンジンによって作成されたデータ ファイルが含まれている場合、mongod
は起動しません。
mongod
には、指定されたdbPath
に対する読み取りおよび書込み権限が必要です。
ウイルス対策 (AV) スキャナーまたはエンドポイント検出および応答 (EDR) スキャナーを使用する場合は、database storage path
と database log path
をスキャンから除外するように設定します。
database storage path
内のデータファイルは圧縮されています。さらに、暗号化されたストレージ エンジンを使用する場合は、データファイルも暗号化されます。これらのファイルをスキャンする際の I/O と CPU のコストによって、パフォーマンスが大幅に低下するおそれがあり、またセキュリティ上のメリットもありません。
database storage path
および database log path
のディレクトリを除外しないと、重要なファイルがスキャナーによって隔離または削除されるおそれがあります。ファイルがの欠損または隔離が原因で、データベースが破損し、MongoDB インスタンスがクラッシュする可能性があります。
同時実行性
WiredTiger
WiredTigerは、コレクション内のドキュメントへのリーダーとライターによる同時アクセスをサポートします。クライアントは書込み操作の進行中にドキュメントを読み取ることができ、複数のスレッドがコレクション内のさまざまなドキュメントを同時に変更できます。
Tip
以下も参照してください。
「十分な RAM と CPU を割り当てる」では、WiredTiger が複数の CPU コアを活用する方法と、操作スループットを向上させる方法について説明しています。
データの整合性
ジャーナリング
MongoDB は、ディスク上のジャーナルへの先行書込みログを使用します。ジャーナリングにより、クラッシュやその他の重大な障害によりmongod
が終了した場合に、ジャーナルに書き込まれたがデータファイルに書き込まれなかった書込み操作を MongoDB が迅速に再開できることが保証されます。
クラッシュが発生した後にmongod
がデータファイルを回復し、データファイルを有効な状態で維持できるようにするために、ジャーナリングを有効のままにします。 詳細については、「ジャーナリング」を参照してください。
WiredTiger ストレージ エンジンを使用するレプリカセット メンバーに対して、 --nojournal
オプションまたはstorage.journal.enabled: false
を指定することはできません。
読み取り保証(read concern)
バージョン 3.2 で追加。
書き込みリクエスト確認をする場合は、非公式のコンシステントセッションを使用して自分の書き込みを読み取ることができます。
書込み保証 (write concern)
書込み保証 は書き込み操作に対して MongoDB から要求される確認応答のレベルを表します。 書込み保証のレベルは、書き込み操作がどれだけ早く戻るかに影響します。 書込み操作の書込み保証が脆弱な場合、それらはすぐに返されます。 書込み保証が強い場合、クライアントは書き込み操作を送信した後、MongoDB が要求された書込み保証レベルで書き込み操作を確認するまで待機する必要があります。 書込み保証が十分でないと、クライアントからは書き込み操作は成功したように見えても、サーバー障害が発生した場合には持続しないことがあります。
導入環境に適した書込み保証レベルの選択に関する詳細については、「書込み保証 (write concern)」ドキュメントを参照してください。
ネットワーキング
信頼できるネットワーク環境の使用
MongoDB は常に信頼できる環境で実行し、不明なマシン、システム、ネットワークからのアクセスをすべて防止するネットワーク ルールを適用します。ネットワーク アクセスに依存する機密性の高いシステムと同様に、MongoDB 配置は、アプリケーション サーバー、監視サービス、その他の MongoDB コンポーネントなど、アクセスを必要とする特定のシステムからのみアクセスできるようにする必要があります。
重要
デフォルトでは、 authorizationは有効になっておらず、 mongod
は信頼できる環境を想定しています。 必要に応じてauthorization
モードを有効にします。 MongoDB でサポートされている認証メカニズムと MongoDB での認可の詳細については、「 自己管理型配置での認証 」および「 自己管理型配置でのロールベースのアクセス制御 」を参照してください。
セキュリティに関する追加情報と考慮事項については、セキュリティ セクションのうち、特に次のドキュメントを参照してください。
Windows ユーザーの場合は、 TCP 構成に関する Windows Server Technet の記事を 検討してください Windows に MongoDB を配置する場合
HTTP インターフェイスの無効化
HTTP インターフェイスはデフォルトで無効になっています。実稼働環境では HTTP インターフェイスを有効にしないでください。
接続プールのサイズを管理する
使用ケースに合わせて接続プールのサイズを調整することで、 mongod
またはmongos
インスタンスの接続リソースが過負荷にならないようにします。現在のデータベースリクエストの通常の件数の 110 ~ 115% から開始し、必要に応じて接続プールのサイズを変更します。接続プールのサイズを調整するには、「接続プール オプション」を参照してください。
connPoolStats
コマンドは、シャーディングされたクラスター内のmongos
およびmongod
インスタンスの、現在データベースへの開いている接続の数に関する情報を返します。
「十分な RAM と CPU を割り当てる」も参照してください。
ハードウェアに関する考慮事項
MongoDB は、コモディティハードウェアを念頭に置いて特別に設計されており、ハードウェア要件や制限はほとんどありません。MongoDB のコアコンポーネントは、x86/x86_64 プロセッサをはじめとするリトル エンディアン ハードウェアで稼働します。クライアントライブラリ(つまり、ドライバー)は、ビッグ エンディアン システムでもリトル エンディアン システムでも実行できます。
十分な RAM と CPU を割り当てる
少なくとも、各mongod
またはmongos
インスタンスが 2 つのリアル コア、または 1 つのマルチコア物理 CPU にアクセスできることを確認してください。
WiredTiger
WiredTiger のストレージ エンジンはマルチスレッド化されており、追加の CPU コアを活用できます。具体的には、アクティブなスレッドの総数 (つまり、利用可能な CPU の数に対する同時操作数)によってパフォーマンスが影響を受ける可能性があります。
スループットは、同時アクティブ処理数が CPU 数まで増加するにつれて増加します。
同時に実行されているアクティブな操作の数が CPU の数をある程度超えると、スループットは低下します。
しきい値は、アプリケーションによって異なります。 スループットを実験して測定することで、アプリケーションに最適な同時アクティブ処理数を判断できます。 mongostat
からの出力は、( ar|aw
)列のアクティブな読み取りまたは書込み数に関する統計を提供します。
WiredTiger を使用する MongoDB では WiredTiger 内部キャッシュとファイルシステム キャッシュの両方を利用します。
デフォルトの WiredTiger 内部キャッシュ サイズは、次のいずれか大きい方です。
(RAM-1 GB)の50%、または
256 MB.
たとえば、合計が4 GB の RAM を備えたシステムでは、WiredTiger キャッシュは1.5 GB の RAM を使用します( 0.5 * (4 GB - 1 GB) =
1.5 GB
)。 逆に、合計が1.25のシステムでは GBのRAM WiredTigerは 256 MB をWiredTigerキャッシュに割り当てます。これはRAMの合計の半分以上で 1 ギガバイト(0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB
)を引いた値であるためです。
注意
コンテナで実行している場合など、場合によっては、データベースのメモリが制約され、システムメモリの合計よりも少なくなることがあります。このような場合、システム メモリの合計ではなく、このメモリ上限が、使用可能な最大 RAM として使用されます。
メモリ制限を確認するには、hostInfo.system.memLimitMB
を参照してください。
デフォルトでは、WiredTiger はすべてのコレクションに Snappy ブロック圧縮を使用し、すべてのインデックスに接頭辞圧縮を使用します。圧縮のデフォルトはグローバルレベルで構成可能で、コレクションおよびインデックスの作成時にコレクションごとおよびインデックスごとに設定することもできます。
WiredTiger 内部キャッシュのデータには、ディスク上の形式とは異なる表現が使用されます。
ファイルシステムキャッシュ内のデータは、データファイルを圧縮する利点も含め、ディスク上のフォーマットと同じです。ファイルシステム キャッシュは、ディスク I/O を削減するためにオペレーティング システムによって使用されます。
WiredTiger 内部キャッシュに読み込まれたインデックスのデータ表現は、ディスク上の形式とは異なりますが、インデックスの接頭辞圧縮を利用して RAM の使用量を減らすことができます。インデックスの接頭辞圧縮は、インデックスのあるフィールドから一般的な接頭辞の重複を排除します。
WiredTiger 内部キャッシュ内のコレクション データは非圧縮で、ディスク上の形式とは異なる表現を使用します。ブロック圧縮によりディスク上のストレージを大幅に節約できますが、サーバーで操作するにはデータを解凍する必要があります。
ファイルシステム キャッシュを使用すると、MongoDB は WiredTiger キャッシュや他のプロセスによって使用されていないすべての空きメモリを自動的に使用します。
WiredTiger 内部キャッシュのサイズを調整するには、 storage.wiredTiger.engineConfig.cacheSizeGB
と--wiredTigerCacheSizeGB
を参照してください。WiredTiger の内部キャッシュ サイズをデフォルト値より大きくしないようにしてください。
注意
storage.wiredTiger.engineConfig.cacheSizeGB
は WiredTiger の内部キャッシュのサイズを制限します。オペレーティング システムは、使用可能な空きメモリをファイルシステム キャッシュに使用するため、圧縮されたMongoDBデータファイルをメモリに保持できます。さらに、オペレーティング システムは、空き RAM を使用して、ファイル システム ブロックとファイル システム キャッシュをバッファリングします。
RAM の利用者増加に対応するためには、WiredTiger の内部キャッシュ サイズを減らす必要がある場合があります。
デフォルトの WiredTiger 内部キャッシュ サイズ値は、マシンごとに単一の mongod
インスタンスが存在することを想定しています。1 台のマシンに複数の MongoDB インスタンスがある場合は、設定値を減らして他の mongod
インスタンスに対応できるようにしてください。
システムで使用可能なすべての RAM にアクセスできないコンテナ(lxc
、cgroups
、Docker など)で mongod
を実行する場合は、コンテナで使用可能な RAM の量よりも小さい値に storage.wiredTiger.engineConfig.cacheSizeGB
を設定する必要があります。正確な量は、コンテナ内で実行中の他のプロセスによって異なります。memLimitMB
を参照してください。
キャッシュと削除率の統計を表示するには、wiredTiger.cache
コマンドから返されるserverStatus
フィールドを参照してください。
圧縮と暗号化
暗号化を使用する場合、AES-NI 命令セット拡張を搭載した CPU ではパフォーマンス上の大きな利点が得られます。MongoDB Enterprise を 暗号化されたストレージエンジン とともに使用している場合は、パフォーマンスを向上させるために AES-NI をサポートする CPU を選択してください。
ソリッドステートディスク(SSD)を使用する
MongoDB は、SATA SSD(ソリッド ステート ディスク)を使用した場合、優れた結果と優れた価格性能比を実現します。
SSD が安価で入手できる場合は、SSD を使用してください。
多くの場合はコモディティ(SATA)スピニングドライブが適しています。これは、高価なスピニングドライブを使用してもランダム I/O のパフォーマンスはそれほど劇的に改善しないためです(約 2 倍程度にしかなりません)。SSD を使用するか、RAM を増やすと、I/O スループットの向上に効果的です。
MongoDB および NUMA ハードウェア
NUMA(不均等メモリアクセス)システムで MongoDB を実行すると、一定期間パフォーマンスが低下したり、システム プロセスの使用率が高くなったりするなど、さまざまな運用上の問題が発生する可能性があります。
MongoDB サーバーとクライアントを NUMA ハードウェアで動作させる場合は、メモリインターリーブポリシーを設定して、ホストが非 NUMA で動作するようにする必要があります。MongoDB は、Linux(バージョン 2.0 以降)および Windows(バージョン 2.6 以降)のマシンにデプロイすると、起動時に NUMA 設定を確認します。NUMA 構成によってパフォーマンスが低下する可能性がある場合、MongoDB は警告を出力します。
Tip
以下も参照してください。
MySQL の「swap insanity」問題と NUMA の影響に関する記事では、NUMA がデータベースに与える影響について説明されています。この記事では、NUMA の概要とその目的が紹介され、その目的が本番環境のデータベースとどのように適合しないかが示されています。このブログ記事は MySQL に対する NUMA の影響について説明していますが、MongoDB においても同様の問題が存在します。
NUMA: 概要 。
Windows での NUMA の構成
Windows では、マシンの BIOS を通じてメモリインターリーブを有効にする必要があります。詳細については、システムのマニュアルを参照してください。
Linux での NUMA の構成
Linuxでは、zone reclaim を無効にし、mongod
および mongos
インスタンスが numactl
によって起動されるようにする必要があります。これは通常、プラットフォームの init システムを通じて構成されます。MongoDB で使用する NUMA を適切に無効にするには、これらの操作の両方を実行する必要があります。
以下のコマンドのいずれかを使用して、zone reclaim を無効化します。
echo 0 | sudo tee /proc/sys/vm/zone_reclaim_mode sudo sysctl -w vm.zone_reclaim_mode=0 mongod
とmongos
がnumactl
によって開始されていることを確認します。これは通常、プラットフォームの init システムで構成されます。以下のコマンドを実行して、使用中のプラットフォームでどの init システムが使用されているかを調べます。ps --no-headers -o comm 1 systemd
の場合、プラットフォームは systemd init システムを使用しているため、MongoDB のサービス ファイルを編集するには以下の systemd タブの手順に必ず従う必要があります。init
の場合、プラットフォームは SysV Init システムを使用しているため、この手順を実行する必要はありません。SysV Init のデフォルトの MongoDB init スクリプトには、numactl
経由で MongoDB インスタンスを起動するために必要なステップがデフォルトで含まれています。自身で init スクリプトを管理している場合(つまり、これらの init システムのいずれも使用していない場合)は、必ず以下の「カスタム init スクリプト」タブの手順に従ってカスタム init スクリプトを編集します。
すべての構成サーバー 、
mongos
インスタンス、およびクライアントを含む、mongod
インスタンスのそれぞれを起動するには、numactl
を使用する必要があります。それぞれのデフォルトのsystemdサービスファイルを以下のように編集します。デフォルトの MongoDB サービスファイルをコピーします。
sudo cp /lib/systemd/system/mongod.service /etc/systemd/system/ /etc/systemd/system/mongod.service
ファイルを編集し、ExecStart
ステートメントを次のように更新します。/usr/bin/numactl --interleave=all 例
既存の
ExecStart
ステートメントが次のようになっている場合:ExecStart=/usr/bin/mongod --config /etc/mongod.conf この文を次のように更新します。
ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --config /etc/mongod.conf systemd
に変更を適用します:sudo systemctl daemon-reload 実行中の
mongod
インスタンスを再起動します。sudo systemctl stop mongod sudo systemctl start mongod 該当する場合は、
mongos
インスタンスに対してこれらの手順を繰り返します。
すべての構成サーバー 、
mongos
インスタンス、およびクライアントを含む、mongod
インスタンスのそれぞれを起動するには、numactl
を使用する必要があります。まだインストールされていない場合は、プラットフォーム用の
numactl
をインストールしてください。numactl
パッケージのインストールについては、オペレーティング システムのドキュメントを参照してください。それぞれのカスタム初期化スクリプトを設定して、
numactl
経由で各 MongoDB インスタンスを起動します。numactl --interleave=all <path> <options> ここで、
<path>
起動するプログラムへのパスであり、<options>
はそのプログラムに渡すオプションの引数です。例
numactl --interleave=all /usr/local/bin/mongod -f /etc/mongod.conf
ディスクおよびストレージ システム
Swap
MongoDBは、スワップからのデータの取得が RAM 内のデータへのアクセスよりも常に遅くなるため、スワップを回避または最小限に抑えることができる場合に最高のパフォーマンスを発揮します。ただし、MongoDB をホストしているシステムの RAM が不足した場合、スワップによって Linux OOM Killer がmongod
プロセスを終了できなくなる可能性があります。
一般的には、次のいずれかのスワップ戦略を選択する必要があります。
システムにスワップ領域を割り当て、メモリ負荷が高い場合のみスワップを許可するようにカーネルを設定する。または、
システムにスワップ領域を割り当てないで、スワップを完全に無効にするようにカーネルを設定します。
これらのガイドラインに従って Linux システムでスワップを構成する手順については、「 vm.swappiness の設定」を参照してください。
注意
MongoDB インスタンスが、ウェブサーバーなどの他のソフトウェアも実行するシステムでホストされている場合は、最初のスワップ戦略を選択する必要があります。この場合はスワップを無効にしないでください。可能であれば、MongoDB を専用のシステムで実行することを強くお勧めします。
RAID
ストレージ層のパフォーマンスを最適化するには、RAID-10 でバックアップされたディスクを使用します。RAID-5 および RAID-6 は通常、MongoDB の配置をサポートするのに十分なパフォーマンスを提供しません。
リモート ファイルシステム(NFS)
WiredTiger storage engine を使用すると、リモート ファイル システムがISO/IEC 9945-1:1996 (POSIX.1) に準拠している場合、WiredTiger オブジェクトをリモート ファイル システムに保存できます。リモート ファイル システムはローカル ファイル システムよりも遅いことが多いため、ストレージにリモート ファイル システムを使用するとパフォーマンスが低下する可能性があります。
NFS を使用する場合は、次の NFS オプションを/etc/fstab
ファイルに追加します。
bg
hard
nolock
noatime
nointr
カーネルのバージョンによっては、これらの値の一部が既にデフォルトとして設定されている場合があります。詳細については、プラットフォームのドキュメントを参照してください。
コンポーネントを異なるストレージデバイスに分離
パフォーマンスを向上させるには、アプリケーションのアクセスと書き込みパターンに基づいて、データベースのデータ、ジャーナル、およびログを異なるストレージデバイスに分離することを検討します。コンポーネントを個別のファイルシステムとしてマウントし、シンボリックリンクを使用して各コンポーネントのパスを格納しているデバイスにマップします。
WiredTiger storage engineの場合、インデックスを別のストレージ デバイスに格納することもできます。storage.wiredTiger.engineConfig.directoryForIndexes
を参照してください。
注意
異なるストレージ デバイスを使用すると、ファイルが異なるデバイスとボリュームに保存されるため、データのスナップショット形式のバックアップを作成する機能に影響します。
スケジューリング
仮想またはクラウドでホストされるデバイスのスケジューリング
ハイパーバイザーを介して仮想マシンのインスタンスに接続されているローカル ブロック デバイスや、クラウド ホスティング プロバイダーによってホストされているローカル ブロック デバイスの場合、最高のパフォーマンスを得るには、ゲスト オペレーティング システムが CFQ スケジューラーを使用する必要があります。cfq
スケジューラーを使用すると、オペレーティングシステムの I/O スケジューリングは基盤となるハイパーバイザーに従います。
注意
次の条件がすべて満たされている場合、 noop スケジューラをスケジューリングに使用できます。
ハイパーバイザーは VMware です。
レプリカセットのトポロジー、またはシャーディングされたクラスターが使用されます。
仮想マシンは、同じ仮想ホスト上にあります。
DB パスを含む基礎となるストレージは、共通の LUN ブロックストアです。
物理サーバーのスケジューリング
物理サーバーの場合、オペレーティングシステムは deadline スケジューラーを使用する必要があります。deadline スケジューラーは、リクエストごとの最大レイテンシを制限し、データベースアプリケーションに最適な良好なスループットを維持します。
アーキテクチャ
レプリカセット
レプリカセットのデプロイに関するアーキテクチャ上の考慮事項の概要については、「レプリカセットアーキテクチャ」ドキュメントを参照してください。
シャーディングされたクラスター
本番配置に推奨されるシャーディングされたクラスターのアーキテクチャの概要については、「シャーディングされたクラスターの実稼働アーキテクチャ」を参照してください。
圧縮
WiredTiger は、次のいずれかの圧縮ライブラリを使用してコレクション データを圧縮できます。
- Snappy
zlib
またはzstd
よりも圧縮率は低くなりますが、どちらの場合よりも CPU コストが低くなります。
- zlib
snappy
よりも圧縮率が高くなりますが、snappy
およびzstd
よりも CPU コストが高くなります。
- zstd(MongoDB 4.2 以降で利用可能)
snappy
およびzlib
よりも圧縮率が高くなり、CPU コストはzlib
よりも低くなります。
デフォルトでは、WiredTiger は snappy 圧縮ライブラリを使用します。圧縮設定を変更するには、 storage.wiredTiger.collectionConfig.blockCompressor
を参照してください。
WiredTiger はデフォルトですべてのインデックスに対して接頭辞圧縮を使用します。
クロック同期
MongoDBコンポーネントは、時間に依存する操作をサポートするために論理クロックを保持します。 NTP の 使用 ホスト マシンのクロックを同期するため、コンポーネント間のクロック ドリフトのリスクが軽減されます。コンポーネント間のクロック ドリフトにより、次のような時間依存の操作の誤った動作または正常な動作が発生する可能性が高まります。
特定の MongoDB コンポーネントの基盤となるシステム クロックが、同じ配置内の他のコンポーネントから 1 年以上ずれている場合、ノード間の通信が信頼できなくなるか、完全に停止する可能性があります。
maxAcceptableLogicalClockDriftSecs
パラメータは、コンポーネント間の許容クロック ドリフトの量を制御します。maxAcceptableLogicalClockDriftSecs
の値が低いクラスターでは、クロック ドリフトの許容度もそれに応じて低くなります。異なるシステム クロックを持つ 2 つのクラスター ノードは、現在のクラスターまたはシステム時間を返す操作に対して、異なる値を返す場合があります (例:
Date()
、NOW
、CLUSTER_TIME
)。タイムキーピングに依存する機能は、MongoDB コンポーネント間のクロックドリフトがあるクラスターでは、一貫性のない、または予測できない動作をする可能性があります。
NTP3.4.6
3.2.17
同期は、Wired Tiger ストレージ エンジンで または 未満の MongoDB を実行する配置に必要です。クロック ドリフトは チェックポイントでのハング につながる可能性があります。 。この問題は MongoDB 3で修正されました。 4 。 6 + 変更ログと MongoDB 3 。 2 。 17 + リリースノートと は、MongoDB 3のすべてのポイント リリースで解決されています。 6 、 4 。 0 、 4 。 2以降のリリース。
プラットフォーム固有の考慮事項
MongoDB on Linux
カーネルとファイルシステム
Linux 上の本番環境で MongoDB を実行する場合は、Linux カーネル バージョン 2.6.36 以降と XFS または EXT4 ファイル システムを使用する必要があります。可能であれば、MongoDB でのパフォーマンスが向上するため、XFS を使用してください。
WiredTiger ストレージ エンジンでは、WiredTiger で EXT4 を使用する際に発生する可能性のあるパフォーマンスの問題を回避するために、データを保持するノードに XFS を使用することが強く推奨されます。
一般に、XFS ファイル システムを使用する場合は、少なくとも Linux カーネルのバージョン
2.6.25
を使用してください。EXT4 ファイル システムを使用する場合は、少なくとも Linux カーネルのバージョン
2.6.28
以上を使用してください。Red Hat Enterprise Linux および CentOS では、少なくとも Linux カーネルのバージョン
2.6.18-194
以上を使用してください。
System C ライブラリ
MongoDB は Linux 上で GNU C ライブラリ(glibc)を使用します。通常、各 Linux ディストリビューションは、このライブラリの検証済みバージョンを提供します。最良の結果を得るには、このシステム提供バージョンで利用可能な最新の更新版を使用してください。インストールされているバージョンが最新であるかどうかは、システムのパッケージ マネージャーを使用して確認できます。以下に例を示します。
RHEL / CentOS では、次のコマンドでシステム提供の GNU C ライブラリが更新されます。
sudo yum update glibc Ubuntu / Debianでは、次のコマンドでシステム提供のGNU Cライブラリが更新されます。
sudo apt-get install libc6
fsync()
ディレクトリ
重要
MongoDB には、ディレクトリ上のfsync()
をサポートするファイルシステムが必要です。たとえば、HGFS や Virtual Box の共有フォルダはこの操作をサポートしていません。
vm.swappiness
を1
または に設定します0
Swappiness は、仮想記憶マネージャーの動作に影響を与える Linux カーネル設定です。vm.swappiness
設定の範囲は0
から100
までで、値が大きいほど、RAM からページをドロップするよりもメモリページをディスクにスワップすることを優先します。
0
に設定すると、スワップが完全に無効になります[4] 。1
に設定すると、メモリ不足の問題を回避するためにのみカーネルがスワップできるようになります。60
に設定すると、カーネルはディスクに頻繁にスワップするように指示され、多くの Linux ディストリビューションではこれがデフォルト値になります。100
に設定すると、カーネルは積極的にディスクにスワップします。
MongoDB は、スワッピングを回避または最小限に抑えることができる場合に最高のパフォーマンスを発揮します。そのため、アプリケーションのニーズとクラスター構成に応じて、vm.swappiness
を 1
または 0
に設定する必要があります。
注意
ほとんどのシステム プロセスとユーザー プロセスは cgroup 内で実行され、デフォルトではvm.swappiness
が60
に設定されます。RHEL / CentOSを実行中であれば、vm.force_cgroup_v2_swappiness
を1
に設定して、指定されたvm.swappiness
値がcgroup のデフォルトを上書きすることを確認します。
[4] | 3.5 より前の Linux カーネル バージョン、または2.6.32-303 より前のRHEL / CentOS カーネル バージョンでは、 vm.swappiness を0 に設定しても、特定の緊急事態でカーネルをスワップできます。 |
注意
MongoDB インスタンスが、Web サーバーなどの他のソフトウェアも実行するシステムでホストされている場合は、 vm.swappiness
を1
に設定する必要があります。可能であれば、MongoDB を専用のシステムで実行することを強くお勧めします。
システムの現在の swappiness 設定を確認するには、次のコマンドを実行します。
cat /proc/sys/vm/swappiness システム上の swappiness を変更するには:
/etc/sysctl.conf
ファイルを編集し、次の行を追加します。vm.swappiness = 1 次のコマンドを実行して、設定を適用します。
sudo sysctl -p
注意
RHEL / CentOSを実行中で、 tuned
パフォーマンスプロファイルを使用している場合は、選択したプロファイルを編集して、 vm.swappiness
を 1
または 0
に設定する必要があります。
推奨構成
すべてのMongoDBデプロイ:
ネットワーク タイム プロトコル(NTP)を使用して、ホスト間で時間を同期します。これは、シャーディングされたクラスターでは特に重要です。
WiredTiger ストレージエンジンについては、次の推奨事項を考慮してください。
データベース ファイルを含むストレージ ボリュームの
atime
をオフにします。ulimit 参照の推奨事項に従って、プラットフォームの
ulimit
設定を調整します。ulimit
値が低いと、MongoDB の使用頻度が高い場合に悪影響が生じ、MongoDB プロセスへの接続が失敗し、サービスが失われる可能性があります。注意
オープンしているファイル数の
ulimit
値が64000
未満の場合、MongoDB は起動警告を生成します。THP(Transparent Huge Pages)を無効化します。MongoDB は、通常の(4096 バイト)仮想記憶ページを使用するとパフォーマンスが向上します。「Transparent Huge Pages」を参照してください。
BIOS で NUMA を無効にします。 それが不可能な場合は、「 NUMA ハードウェア上の MongoDB 」を参照してください。
デフォルトの MongoDB ディレクトリ パスまたはポートを使用していない場合は、 SELinux for MongoDB を構成します。
必要な構成については、「 SELinux for MongoDB の 構成 」および「 SELinux for MongoDB Enterprise の 構成 」を参照してください。
注意
SELinux を使用している場合、サーバー側の JavaScriptを必要とする MongoDB 操作ではセグメント違反エラーが発生します。「JavaScript のサーバー側実行を無効にする」では、サーバー側 JavaScript の実行を無効にする方法について解説しています。
WiredTiger ストレージエンジン:
ストレージメディアタイプ(スピニングディスク、SSD など)に関係なく、先読みの設定を 8 ~ 32 に設定します。
readahead が高い場合は、一般に、連続した I/O 操作がメリットとなります。 MongoDB のディスク アクセス パターンは通常ランダムであるため、readahead 設定を高く使用してもメリットは限られ、パフォーマンスが低下する可能性があります。 そのため、最適な MongoDB パフォーマンスを得るには、テストで readahead 値が高いほど測定可能で、再現性のある、信頼性の高いベネフィットが示されない限り、readahead を8から32の間で設定します。 MongoDB の商用サポートでは、代替の readahead 構成に関するアドバイスとガイダンスが提供されます。
MongoDB および TLS/SSL ライブラリ
Linux プラットフォームでは、MongoDB ログに次のいずれかのステートメントが記録されることがあります。
<path to TLS/SSL libs>/libssl.so.<version>: no version information available (required by /usr/bin/mongod) <path to TLS/SSL libs>/libcrypto.so.<version>: no version information available (required by /usr/bin/mongod)
これらの警告は、システムの TLS/SSL ライブラリが、 mongod
がコンパイルされた TLS/SSL ライブラリと異なることを示しています。通常、これらのメッセージには介入は必要ありませんが、次の操作を使用して、 mongod
に期待されるシンボル バージョンを判別できます。
objdump -T <path to mongod>/mongod | grep " SSL_" objdump -T <path to mongod>/mongod | grep " CRYPTO_"
これらの操作は、次のいずれかの行のような出力を返します。
0000000000000000 DF *UND* 0000000000000000 libssl.so.10 SSL_write 0000000000000000 DF *UND* 0000000000000000 OPENSSL_1.0.0 SSL_write
この出力の最後の 2 つの文字列は、シンボルのバージョンとシンボル名です。これらの値を次の操作によって返される値と比較して、シンボル バージョンの不一致を検出します。
objdump -T <path to TLS/SSL libs>/libssl.so.1* objdump -T <path to TLS/SSL libs>/libcrypto.so.1*
この手順は正確でも網羅的でもありません。 libcrypto
ライブラリのmongod
で使用される多くのシンボルはCRYPTO_
で始まりません。
MongoDB on Windows
WiredTiger ストレージ エンジンを使用する MongoDB インスタンスの場合、Windows でのパフォーマンスは Linux でのパフォーマンスに匹敵します。
仮想環境での MongoDB
このセクションでは、より一般的な仮想環境で MongoDB を実行する際の考慮事項について説明します。
すべてのプラットフォームで、スケジュール設定を検討してください。
Amazon Web Services EC2
考慮すべきパフォーマンス構成は 2 つあります。
パフォーマンステストやベンチマークのための再現可能なパフォーマンス、および
未加工の最大パフォーマンス
どちらの構成でも EC2 のパフォーマンスを調整するには、次の手順を実行する必要があります。
拡張ネットワーキング をAmazon Web Services 有効にする : インスタンス用。すべてのインスタンス タイプが拡張ネットワーキングをサポートしているわけではありません。
拡張ネットワーキングの詳細については、Amazon Web Services のドキュメント を参照してください 。
EC2 での再現可能なパフォーマンスをさらに重視する場合は、次のことも行う必要があります。
ストレージにはプロビジョンド IOPS を使用し、ジャーナルとデータには別々のデバイスを使用します。パフォーマンスは刻々と変化するので、ほとんどのインスタンスタイプで利用できるエフェメラル(SSD)ストレージは使用しないでください。(
i
シリーズは特筆すべき例外ですが、非常に高価です)DVFS および CPU 省電力モードを無効にします。
ハイパースレッディングを無効にします。
メモリの局所性を単一のソケットにバインドするには、
numactl
を使用します。
Azure
Premium Storage の 使用 。Microsoft Azure には、標準ストレージとプレミアム ストレージの 2 つの一般的なタイプのストレージがあります。 Azure 上の MongoDB では、standard ストレージを使用する場合よりも Premium ストレージを使用する場合のパフォーマンスが向上します。
Azure ロード バランサーの TCP アイドル タイムアウトはデフォルトで 240 秒です。そのため、Azure システムの TCP キープアライブがこの値より大きいと、接続が自動的に切断される可能性があります。この問題を改善するには、 tcp_keepalive_time
を 120 に設定する必要があります。
Linux でキープアライブ設定を表示するには、次のいずれかのコマンドを使用します。
sysctl net.ipv4.tcp_keepalive_time または:
cat /proc/sys/net/ipv4/tcp_keepalive_time 値は秒単位で測定されます。
注意
設定名に
ipv4
が含まれていますが、tcp_keepalive_time
値は IPv4 と IPv6 の両方に適用されます。tcp_keepalive_time
値を変更するには、次のコマンドのいずれかを使用して、 <value> を秒単位で指定します。sudo sysctl -w net.ipv4.tcp_keepalive_time=<value> または:
echo <value> | sudo tee /proc/sys/net/ipv4/tcp_keepalive_time これらの操作は、システムの再起動後は保持されません。設定を永続化するには、次の行を
/etc/sysctl.conf
に追加し、秒単位で<value>を指定して、マシンを再起動します。net.ipv4.tcp_keepalive_time = <value> 300
秒 (5 分)を超えるキープアライブ値は、mongod
およびmongos
ソケットで上書きされ、300
秒に設定されます。
Windows でキープアライブ設定を表示するには、以下のコマンドを実行します。
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime レジストリ値はデフォルトでは存在しません。値が存在しない場合に使用されるシステムのデフォルトは、
7200000
ミリ秒または 16 進数の0x6ddd00
です。KeepAliveTime
の値を変更するには、管理者アカウントのCommand Promptで次のコマンドを使用します。<value>
は 16 進数で表されます (例:120000
は0x1d4c0
です)。reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v KeepAliveTime /d <value> Windows ユーザーは、Windows システム上に MongoDB を配置する場合の keepalive 設定の詳細について、KeepAliveTimeに関するWindows Server Technet の記事を検討してください。keepalive の値が 600000 ミリ秒(10 分)以上の場合、
mongod
およびmongos
は、keepalive を無視します。
VMware
MongoDB は VMware と互換性があります。
VMwareはメモリのオーバーコミットをサポートしており、物理マシンの空き容量よりも多くのメモリを仮想マシンに割り当てることができます。メモリがオーバーコミットされると、ハイパーバイザーは仮想マシン間でメモリを再割り当てします。VMware のバルーン ドライバー(vmmemctl
)は、最も価値が低いと見なされるページを再利用します。
バルーン ドライバーはゲスト オペレーティング システム内に存在します。 特定の構成では、バルーン ドライバーが展開すると、MongoDB のメモリ管理に干渉し、MongoDB のパフォーマンスに影響を与える可能性があります。
バルーン ドライバーとメモリ オーバーコミット機能によるパフォーマンスへの悪影響を防ぐには、MongoDB を実行する仮想マシンに全量のメモリを予約します。仮想マシンに適切な量のメモリを予約しておくと、ハイパーバイザーでメモリが圧迫されても、ローカル オペレーティングシステムでバルーンが膨張するのを防ぐことができます。
バルーン ドライバーとメモリのオーバーコミット機能は、特定の構成で MongoDB のパフォーマンスに悪影響を与える可能性がありますが、これらの機能を無効にしないでください。これらの機能を無効にすると、ハイパーバイザーがスワップ領域を使用してメモリ要求を満たす可能性があり、パフォーマンスに悪影響を及ぼします。
VMwareのアフィニティ ルールを設定して、仮想マシンが特定の ESX/ESXi ホスト上に維持します。仮想マシンを別のホストに手動で移行する必要があり、仮想マシン上の mongod
インスタンスがプライマリである場合は、最初にプライマリを step down
して、次に shut down the instance
する必要があります。
vMotion のネットワーク ベストプラクティスに従う および VMKernel 。ベストプラクティスに従うと、パフォーマンスの問題が発生し、レプリカセットとシャーディングされたクラスターの高可用性メカニズムに影響する可能性があります。
MongoDB を実行している仮想マシンを複製することが可能です。この機能を使用して、新しい仮想ホストを起動してレプリカセットのノードとして追加することができます。ジャーナリングが有効になっている仮想マシンをクローンする場合は、クローンスナップショットが有効になります。ジャーナリングを使用していない場合は、まずmongod
を停止し、次に VM のクローンを作成し、最後にmongod
を再起動します。
KVM
MongoDBは KVM と互換性があります。
KVM はメモリのオーバーコミットをサポートしており、物理マシンの空き容量よりも多くのメモリを仮想マシンに割り当てることができます。メモリがオーバーコミットされると、ハイパーバイザーは仮想マシン間でメモリを再割り当てします。KVM のバルーン ドライバーは、最も価値が低いと判断されたページを再利用します。
バルーン ドライバーはゲスト オペレーティング システム内に存在します。 特定の構成では、バルーン ドライバーが展開すると、MongoDB のメモリ管理に干渉し、MongoDB のパフォーマンスに影響を与える可能性があります。
バルーン ドライバーとメモリ オーバーコミット機能によるパフォーマンスへの悪影響を防ぐには、MongoDB を実行する仮想マシンに全量のメモリを予約します。仮想マシンに適切な量のメモリを予約しておくと、ハイパーバイザーでメモリが圧迫されても、ローカル オペレーティングシステムでバルーンが膨張するのを防ぐことができます。
バルーン ドライバーとメモリのオーバーコミット機能は、特定の構成で MongoDB のパフォーマンスに悪影響を与える可能性がありますが、これらの機能を無効にしないでください。これらの機能を無効にすると、ハイパーバイザーがスワップ領域を使用してメモリ要求を満たす可能性があり、パフォーマンスに悪影響を及ぼします。
パフォーマンス モニタリング
注意
MongoDB バージョン 4.0 以降では、スタンドアロンとレプリカセットの無料クラウドモニタリングが提供されます。 詳細については、「無料モニタリング 」を参照してください。
iostat
Linux では、 iostat
コマンドを使用して、ディスク I/O がデータベースのボトルネックになっているかどうかを確認します。iostat を実行するときに秒数を指定して、サーバーの起動以降の時間をカバーする統計情報を表示しないようにします。
たとえば、次のコマンドは、表示される各レポートの拡張統計と時間を、1 秒間隔で MB/ 秒単位のトラフィックとともに表示します。
iostat -xmt 1
iostat
からのキー フィールド:
%util
これは簡単なチェックに最も役立つフィールドで、デバイスまたはドライブが使用されている時間の割合を示します。avgrq-sz
: リクエストの平均サイズ。この値が小さい場合は、よりランダムな I/O 操作があるこを示します。
bwm-ng
bwm-ng は、ネットワークの使用状況を監視するためのコマンドライン ツールです。ネットワークベースのボトルネックが疑われる場合は、bwm-ng
を使用して診断プロセスを開始できます。
バックアップ
MongoDB データベースのバックアップを作成するには、「MongoDB バックアップ方法の概要」を参照してください。