Docs Menu
Docs Home
/
MongoDBマニュアル
/ /

自己管理型配置のプロダクション ノート

項目一覧

  • プラットフォーム サポート
  • プラットフォーム サポート ノート
  • プラットフォーム サポート マトリクス
  • MongoDB dbPath
  • 同時実行性
  • データの整合性
  • ネットワーキング
  • ハードウェアに関する考慮事項
  • アーキテクチャ
  • 圧縮
  • クロック同期
  • プラットフォーム固有の考慮事項
  • パフォーマンス モニタリング
  • バックアップ

このページでは、特に本番環境で実行する場合の 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 を参照してください。

MongoDB には、最低限、次の x86_64マイクロアーキテクチャが必要です。

  • Intel x86_64の場合、MongoDB には次のいずれかが必要です。

    • Sandy Bridge 以降の Core プロセッサ、または

    • Tiger Lake 以降の Celeron または Pentium プロセッサ。

  • AMD x86_64の場合、MongoDB には以下が必要です。

    • Bulldozer 以降のプロセッサ。

MongoDB 5.0 以降、 mongodmongos 、およびレガシーmongoshell は、この最小マイクロアーキテクチャ要件を満たさないx86_64プラットフォームのサポーを終了しました。

arm64上の MongoDB には ARMv8.2-A、またはそれ以降のマイクロアーキテクチャが必要です。

MongoDB 5.0 以降、 mongodmongos 、およびレガシーmongoshell は、この最小マイクロアーキテクチャ要件を満たさない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 9
s390x
エンタープライズ
RHEL/Rocky/Alma 8
s390x
エンタープライズ
5.0.9+
RHEL/CentOS 7
s390x
エンタープライズ
RHEL/CentOS 7
s390x
Community
[1]12345678 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 互換性を提供する義務を果たすことが前提となります。

Tip

以下も参照してください。

最新の安定版リリースを使用していることを確認してください。

すべての MongoDB のリリースは、MongoDB ダウンロード センターページで入手できます。パッケージ マネージャーを使用してインストールする場合でも、MongoDB ダウンロード センターは、現在の安定したリリースを確認するのに適した場所です。

その他の MongoDB 製品については、MongoDB ダウンロード センター ページまたはそれぞれのドキュメントを参照してください。

dbPathディレクトリ内のファイルは、構成されたストレージ エンジンに対応している必要があります。dbPath--storageEngine で指定されたストレージ エンジン以外のストレージ エンジンによって作成されたデータ ファイルが含まれている場合、mongodは起動しません。

mongodには、指定されたdbPathに対する読み取りおよび書込み権限が必要です。

ウイルス対策 (AV) スキャナーまたはエンドポイント検出および応答 (EDR) スキャナーを使用する場合は、database storage pathdatabase log path をスキャンから除外するように設定します。

database storage path 内のデータファイルは圧縮されています。さらに、暗号化されたストレージ エンジンを使用する場合は、データファイルも暗号化されます。これらのファイルをスキャンする際の I/O と CPU のコストによって、パフォーマンスが大幅に低下するおそれがあり、またセキュリティ上のメリットもありません。

database storage path および database log path のディレクトリを除外しないと、重要なファイルがスキャナーによって隔離または削除されるおそれがあります。ファイルがの欠損または隔離が原因で、データベースが破損し、MongoDB インスタンスがクラッシュする可能性があります。

WiredTigerは、コレクション内のドキュメントへのリーダーとライターによる同時アクセスをサポートします。クライアントは書込み操作の進行中にドキュメントを読み取ることができ、複数のスレッドがコレクション内のさまざまなドキュメントを同時に変更できます。

Tip

以下も参照してください。

「十分な RAM と CPU を割り当てる」では、WiredTiger が複数の CPU コアを活用する方法と、操作スループットを向上させる方法について説明しています。

MongoDB は、ディスク上のジャーナルへの先行書込みログを使用します。ジャーナリングにより、クラッシュやその他の重大な障害によりmongodが終了した場合に、ジャーナルに書き込まれたがデータファイルに書き込まれなかった書込み操作を MongoDB が迅速に再開できることが保証されます。

クラッシュが発生した後にmongodがデータファイルを回復し、データファイルを有効な状態で維持できるようにするために、ジャーナリングを有効のままにします。 詳細については、「ジャーナリング」を参照してください。

WiredTiger ストレージ エンジンを使用するレプリカセット メンバーに対して、 --nojournalオプションまたはstorage.journal.enabled: falseを指定することはできません。

バージョン 3.2 で追加

書き込みリクエスト確認をする場合は、非公式のコンシステントセッションを使用して自分の書き込みを読み取ることができます。

書込み保証 は書き込み操作に対して MongoDB から要求される確認応答のレベルを表します。 書込み保証のレベルは、書き込み操作がどれだけ早く戻るかに影響します。 書込み操作の書込み保証が脆弱な場合、それらはすぐに返されます。 書込み保証が強い場合、クライアントは書き込み操作を送信した後、MongoDB が要求された書込み保証レベルで書き込み操作を確認するまで待機する必要があります。 書込み保証が十分でないと、クライアントからは書き込み操作は成功したように見えても、サーバー障害が発生した場合には持続しないことがあります。

導入環境に適した書込み保証レベルの選択に関する詳細については、「書込み保証 (write concern)」ドキュメントを参照してください。

MongoDB は常に信頼できる環境で実行し、不明なマシン、システム、ネットワークからのアクセスをすべて防止するネットワーク ルールを適用します。ネットワーク アクセスに依存する機密性の高いシステムと同様に、MongoDB 配置は、アプリケーション サーバー、監視サービス、その他の MongoDB コンポーネントなど、アクセスを必要とする特定のシステムからのみアクセスできるようにする必要があります。

重要

デフォルトでは、 authorizationは有効になっておらず、 mongodは信頼できる環境を想定しています。 必要に応じてauthorizationモードを有効にします。 MongoDB でサポートされている認証メカニズムと MongoDB での認可の詳細については、「 自己管理型配置での認証 」および「 自己管理型配置でのロールベースのアクセス制御 」を参照してください。

セキュリティに関する追加情報と考慮事項については、セキュリティ セクションのうち、特に次のドキュメントを参照してください。

Windows ユーザーの場合は、 TCP 構成に関する Windows Server Technet の記事を 検討してください Windows に MongoDB を配置する場合

HTTP インターフェイスはデフォルトで無効になっています。実稼働環境では HTTP インターフェイスを有効にしないでください。

使用ケースに合わせて接続プールのサイズを調整することで、 mongodまたはmongosインスタンスの接続リソースが過負荷にならないようにします。現在のデータベースリクエストの通常の件数の 110 ~ 115% から開始し、必要に応じて接続プールのサイズを変更します。接続プールのサイズを調整するには、「接続プール オプション」を参照してください。

connPoolStatsコマンドは、シャーディングされたクラスター内のmongosおよびmongodインスタンスの、現在データベースへの開いている接続の数に関する情報を返します。

「十分な RAM と CPU を割り当てる」も参照してください。

MongoDB は、コモディティハードウェアを念頭に置いて特別に設計されており、ハードウェア要件や制限はほとんどありません。MongoDB のコアコンポーネントは、x86/x86_64 プロセッサをはじめとするリトル エンディアン ハードウェアで稼働します。クライアントライブラリ(つまり、ドライバー)は、ビッグ エンディアン システムでもリトル エンディアン システムでも実行できます。

少なくとも、各mongodまたはmongosインスタンスが 2 つのリアル コア、または 1 つのマルチコア物理 CPU にアクセスできることを確認してください。

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 にアクセスできないコンテナ(lxccgroups、Docker など)で mongod を実行する場合は、コンテナで使用可能な RAM の量よりも小さい値に storage.wiredTiger.engineConfig.cacheSizeGB を設定する必要があります。正確な量は、コンテナ内で実行中の他のプロセスによって異なります。memLimitMB参照してください。

キャッシュと削除率の統計を表示するには、wiredTiger.cache コマンドから返されるserverStatus フィールドを参照してください。

暗号化を使用する場合、AES-NI 命令セット拡張を搭載した CPU ではパフォーマンス上の大きな利点が得られます。MongoDB Enterprise を 暗号化されたストレージエンジン とともに使用している場合は、パフォーマンスを向上させるために AES-NI をサポートする CPU を選択してください。

Tip

以下も参照してください。

MongoDB は、SATA SSD(ソリッド ステート ディスク)を使用した場合、優れた結果と優れた価格性能比を実現します。

SSD が安価で入手できる場合は、SSD を使用してください。

多くの場合はコモディティ(SATA)スピニングドライブが適しています。これは、高価なスピニングドライブを使用してもランダム I/O のパフォーマンスはそれほど劇的に改善しないためです(約 2 倍程度にしかなりません)。SSD を使用するか、RAM を増やすと、I/O スループットの向上に効果的です。

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 では、マシンの BIOS を通じてメモリインターリーブを有効にする必要があります。詳細については、システムのマニュアルを参照してください。

Linuxでは、zone reclaim を無効にし、mongod および mongos インスタンスが numactl によって起動されるようにする必要があります。これは通常、プラットフォームの init システムを通じて構成されます。MongoDB で使用する NUMA を適切に無効にするには、これらの操作の両方を実行する必要があります。

  1. 以下のコマンドのいずれかを使用して、zone reclaim を無効化します。

    echo 0 | sudo tee /proc/sys/vm/zone_reclaim_mode
    sudo sysctl -w vm.zone_reclaim_mode=0
  2. mongodmongosnumactl によって開始されていることを確認します。これは通常、プラットフォームの 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サービスファイルを以下のように編集します。

    1. デフォルトの MongoDB サービスファイルをコピーします。

      sudo cp /lib/systemd/system/mongod.service /etc/systemd/system/
    2. /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
    3. systemdに変更を適用します:

      sudo systemctl daemon-reload
    4. 実行中の mongod インスタンスを再起動します。

      sudo systemctl stop mongod
      sudo systemctl start mongod
    5. 該当する場合は、 mongosインスタンスに対してこれらの手順を繰り返します。

    すべての構成サーバーmongos インスタンス、およびクライアントを含む、mongodインスタンスのそれぞれを起動するには、numactlを使用する必要があります。

    1. まだインストールされていない場合は、プラットフォーム用のnumactlをインストールしてください。numactlパッケージのインストールについては、オペレーティング システムのドキュメントを参照してください。

    2. それぞれのカスタム初期化スクリプトを設定して、 numactl経由で各 MongoDB インスタンスを起動します。

      numactl --interleave=all <path> <options>

      ここで、 <path>起動するプログラムへのパスであり、 <options>はそのプログラムに渡すオプションの引数です。

      numactl --interleave=all /usr/local/bin/mongod -f /etc/mongod.conf

詳しくは、 /process/sys/vm/* のドキュメントを 参照してください

MongoDBは、スワップからのデータの取得が RAM 内のデータへのアクセスよりも常に遅くなるため、スワップを回避または最小限に抑えることができる場合に最高のパフォーマンスを発揮します。ただし、MongoDB をホストしているシステムの RAM が不足した場合、スワップによって Linux OOM Killer がmongodプロセスを終了できなくなる可能性があります。

一般的には、次のいずれかのスワップ戦略を選択する必要があります。

  1. システムにスワップ領域を割り当て、メモリ負荷が高い場合のみスワップを許可するようにカーネルを設定する。または、

  2. システムにスワップ領域を割り当てないで、スワップを完全に無効にするようにカーネルを設定します。

これらのガイドラインに従って Linux システムでスワップを構成する手順については、「 vm.swappiness の設定」を参照してください。

注意

MongoDB インスタンスが、ウェブサーバーなどの他のソフトウェアも実行するシステムでホストされている場合は、最初のスワップ戦略を選択する必要があります。この場合はスワップを無効にしないでください。可能であれば、MongoDB を専用のシステムで実行することを強くお勧めします。

ストレージ層のパフォーマンスを最適化するには、RAID-10 でバックアップされたディスクを使用します。RAID-5 および RAID-6 は通常、MongoDB の配置をサポートするのに十分なパフォーマンスを提供しません。

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 スケジューラーは、リクエストごとの最大レイテンシを制限し、データベースアプリケーションに最適な良好なスループットを維持します。

レプリカセットのデプロイに関するアーキテクチャ上の考慮事項の概要については、「レプリカセットアーキテクチャ」ドキュメントを参照してください。

本番配置に推奨されるシャーディングされたクラスターのアーキテクチャの概要については、「シャーディングされたクラスターの実稼働アーキテクチャ」を参照してください。

Tip

以下も参照してください。

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()NOWCLUSTER_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以降のリリース。

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以上を使用してください。

MongoDB は Linux 上で GNU C ライブラリ(glibc)を使用します。通常、各 Linux ディストリビューションは、このライブラリの検証済みバージョンを提供します。最良の結果を得るには、このシステム提供バージョンで利用可能な最新の更新版を使用してください。インストールされているバージョンが最新であるかどうかは、システムのパッケージ マネージャーを使用して確認できます。以下に例を示します。

  • RHEL / CentOS では、次のコマンドでシステム提供の GNU C ライブラリが更新されます。

    sudo yum update glibc
  • Ubuntu / Debianでは、次のコマンドでシステム提供のGNU Cライブラリが更新されます。

    sudo apt-get install libc6

重要

MongoDB には、ディレクトリ上fsync() をサポートするファイルシステムが必要です。たとえば、HGFS や Virtual Box の共有フォルダはこの操作をサポートしていません

Swappiness は、仮想記憶マネージャーの動作に影響を与える Linux カーネル設定です。vm.swappiness設定の範囲は0から100までで、値が大きいほど、RAM からページをドロップするよりもメモリページをディスクにスワップすることを優先します。

  • 0に設定すると、スワップが完全に無効になります[4]

  • 1に設定すると、メモリ不足の問題を回避するためにのみカーネルがスワップできるようになります。

  • 60に設定すると、カーネルはディスクに頻繁にスワップするように指示され、多くの Linux ディストリビューションではこれがデフォルト値になります。

  • 100に設定すると、カーネルは積極的にディスクにスワップします。

MongoDB は、スワッピングを回避または最小限に抑えることができる場合に最高のパフォーマンスを発揮します。そのため、アプリケーションのニーズとクラスター構成に応じて、vm.swappiness1 または 0 に設定する必要があります。

注意

ほとんどのシステム プロセスとユーザー プロセスは cgroup 内で実行され、デフォルトではvm.swappiness60に設定されます。RHEL / CentOSを実行中であれば、vm.force_cgroup_v2_swappiness1に設定して、指定されたvm.swappiness値がcgroup のデフォルトを上書きすることを確認します。

[4] 3.5より前の Linux カーネル バージョン、または2.6.32-303より前のRHEL / CentOS カーネル バージョンでは、 vm.swappiness0に設定しても、特定の緊急事態でカーネルをスワップできます。

注意

MongoDB インスタンスが、Web サーバーなどの他のソフトウェアも実行するシステムでホストされている場合は、 vm.swappiness1に設定する必要があります。可能であれば、MongoDB を専用のシステムで実行することを強くお勧めします。

  • システムの現在の swappiness 設定を確認するには、次のコマンドを実行します。

    cat /proc/sys/vm/swappiness
  • システム上の swappiness を変更するには:

    1. /etc/sysctl.confファイルを編集し、次の行を追加します。

      vm.swappiness = 1
    2. 次のコマンドを実行して、設定を適用します。

      sudo sysctl -p

注意

RHEL / CentOSを実行中で、 tuned パフォーマンスプロファイルを使用している場合は、選択したプロファイルを編集して、 vm.swappiness1 または 0に設定する必要があります。

すべてのMongoDBデプロイ:

  • ネットワーク タイム プロトコル(NTP)を使用して、ホスト間で時間を同期します。これは、シャーディングされたクラスターでは特に重要です。

WiredTiger ストレージエンジンについては、次の推奨事項を考慮してください。

WiredTiger ストレージエンジン:

  • ストレージメディアタイプ(スピニングディスク、SSD など)に関係なく、先読みの設定を 8 ~ 32 に設定します。

    readahead が高い場合は、一般に、連続した I/O 操作がメリットとなります。 MongoDB のディスク アクセス パターンは通常ランダムであるため、readahead 設定を高く使用してもメリットは限られ、パフォーマンスが低下する可能性があります。 そのため、最適な MongoDB パフォーマンスを得るには、テストで readahead 値が高いほど測定可能で、再現性のある、信頼性の高いベネフィットが示されない限り、readahead を8から32の間で設定します。 MongoDB の商用サポートでは、代替の readahead 構成に関するアドバイスとガイダンスが提供されます。

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_で始まりません。

WiredTiger ストレージ エンジンを使用する MongoDB インスタンスの場合、Windows でのパフォーマンスは Linux でのパフォーマンスに匹敵します。

このセクションでは、より一般的な仮想環境で MongoDB を実行する際の考慮事項について説明します。

すべてのプラットフォームで、スケジュール設定を検討してください。

考慮すべきパフォーマンス構成は 2 つあります。

  • パフォーマンステストやベンチマークのための再現可能なパフォーマンス、および

  • 未加工の最大パフォーマンス

どちらの構成でも EC2 のパフォーマンスを調整するには、次の手順を実行する必要があります。

EC2 での再現可能なパフォーマンスをさらに重視する場合は、次のことも行う必要があります。

  • ストレージにはプロビジョンド IOPS を使用し、ジャーナルとデータには別々のデバイスを使用します。パフォーマンスは刻々と変化するので、ほとんどのインスタンスタイプで利用できるエフェメラル(SSD)ストレージは使用しないでください。(iシリーズは特筆すべき例外ですが、非常に高価です)

  • DVFS および CPU 省電力モードを無効にします。

  • ハイパースレッディングを無効にします。

  • メモリの局所性を単一のソケットにバインドするには、 numactlを使用します。

Premium Storage の 使用 。Microsoft Azure には、標準ストレージとプレミアム ストレージの 2 つの一般的なタイプのストレージがあります。 Azure 上の MongoDB では、standard ストレージを使用する場合よりも Premium ストレージを使用する場合のパフォーマンスが向上します。

Azure ロード バランサーの TCP アイドル タイムアウトはデフォルトで 240 秒です。そのため、Azure システムの TCP キープアライブがこの値より大きいと、接続が自動的に切断される可能性があります。この問題を改善するには、 tcp_keepalive_timeを 120 に設定する必要があります。

注意

システム全体の新しいキープアライブ設定を有効にするには、 mongodおよびmongosプロセスを再起動する必要があります。

  • 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 進数で表されます (例:1200000x1d4c0です)。

    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 を無視します。

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を再起動します。

MongoDBは KVM と互換性があります。

KVM はメモリのオーバーコミットをサポートしており、物理マシンの空き容量よりも多くのメモリを仮想マシンに割り当てることができます。メモリがオーバーコミットされると、ハイパーバイザーは仮想マシン間でメモリを再割り当てします。KVM のバルーン ドライバーは、最も価値が低いと判断されたページを再利用します。

バルーン ドライバーはゲスト オペレーティング システム内に存在します。 特定の構成では、バルーン ドライバーが展開すると、MongoDB のメモリ管理に干渉し、MongoDB のパフォーマンスに影響を与える可能性があります。

バルーン ドライバーとメモリ オーバーコミット機能によるパフォーマンスへの悪影響を防ぐには、MongoDB を実行する仮想マシンに全量のメモリを予約します。仮想マシンに適切な量のメモリを予約しておくと、ハイパーバイザーでメモリが圧迫されても、ローカル オペレーティングシステムでバルーンが膨張するのを防ぐことができます。

バルーン ドライバーとメモリのオーバーコミット機能は、特定の構成で MongoDB のパフォーマンスに悪影響を与える可能性がありますが、これらの機能を無効にしないでください。これらの機能を無効にすると、ハイパーバイザーがスワップ領域を使用してメモリ要求を満たす可能性があり、パフォーマンスに悪影響を及ぼします。

注意

MongoDB バージョン 4.0 以降では、スタンドアロンとレプリカセットの無料クラウドモニタリングが提供されます。 詳細については、「無料モニタリング 」を参照してください。

Linux では、 iostatコマンドを使用して、ディスク I/O がデータベースのボトルネックになっているかどうかを確認します。iostat を実行するときに秒数を指定して、サーバーの起動以降の時間をカバーする統計情報を表示しないようにします。

たとえば、次のコマンドは、表示される各レポートの拡張統計と時間を、1 秒間隔で MB/ 秒単位のトラフィックとともに表示します。

iostat -xmt 1

iostatからのキー フィールド:

  • %utilこれは簡単なチェックに最も役立つフィールドで、デバイスまたはドライブが使用されている時間の割合を示します。

  • avgrq-sz: リクエストの平均サイズ。この値が小さい場合は、よりランダムな I/O 操作があるこを示します。

bwm-ng は、ネットワークの使用状況を監視するためのコマンドライン ツールです。ネットワークベースのボトルネックが疑われる場合は、bwm-ng を使用して診断プロセスを開始できます。

MongoDB データベースのバックアップを作成するには、「MongoDB バックアップ方法の概要」を参照してください。

戻る

管理