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

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）を引いた値であるためです。

デフォルトでは、WiredTiger はすべてのコレクションに Snappy ブロック圧縮を使用し、すべてのインデックスに接頭辞圧縮を使用します。圧縮のデフォルトはグローバルレベルで構成可能で、コレクションおよびインデックスの作成時にコレクションごとおよびインデックスごとに設定することもできます。

WiredTiger 内部キャッシュのデータには、ディスク上の形式とは異なる表現が使用されます。

• ファイルシステムキャッシュ内のデータは、データファイルを圧縮する利点も含め、ディスク上のフォーマットと同じです。ファイルシステム キャッシュは、ディスク I/O を削減するためにオペレーティング システムによって使用されます。

• WiredTiger 内部キャッシュに読み込まれたインデックスのデータ表現は、ディスク上の形式とは異なりますが、インデックスの接頭辞圧縮を利用して RAM の使用量を減らすことができます。インデックスの接頭辞圧縮は、インデックスのあるフィールドから一般的な接頭辞の重複を排除します。

• WiredTiger 内部キャッシュ内のコレクション データは非圧縮で、ディスク上の形式とは異なる表現を使用します。ブロック圧縮によりディスク上のストレージを大幅に節約できますが、サーバーで操作するにはデータを解凍する必要があります。

ファイルシステム キャッシュを使用すると、MongoDB は WiredTiger キャッシュや他のプロセスによって使用されていないすべての空きメモリを自動的に使用します。

WiredTiger 内部キャッシュのサイズを調整するには、 storage.wiredTiger.engineConfig.cacheSizeGBと--wiredTigerCacheSizeGBを参照してください。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 を選択してください。

Windows での NUMA の構成

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

Linux での NUMA の構成

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. 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 スクリプトを編集します。

     
     
   systemd

   カスタム 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/* のドキュメントを 参照してください 。

Swap

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

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

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

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

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

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 を参照してください。

スケジューリング

カーネルとファイルシステム

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() ディレクトリ

vm.swappiness を 1 または 0 に設定する

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

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

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

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

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

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

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

  cat /proc/sys/vm/swappiness

• システム上の swappiness を変更するには:

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

     vm.swappiness = 1

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

     sudo sysctl -p

推奨構成

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

Amazon Web Services EC2

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

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

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

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

• 拡張ネットワーキング をAmazon Web Services 有効にする : インスタンス用。すべてのインスタンス タイプが拡張ネットワーキングをサポートしているわけではありません。

  拡張ネットワーキングの詳細については、Amazon Web Services のドキュメント を参照してください 。

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

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

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

  Tip

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

  プロセッサの状態制御に関する Amazon のドキュメント

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

  Tip

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

  ハイパー スレッディングを無効にする方法に関する Amazon ブログ記事 。

• メモリの局所性を単一のソケットにバインドするには、 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 が動作している仮想マシンをクローンすることができます。この機能を使用して、新しい仮想ホストを配置してレプリカセットのノードとして追加することができます。

KVM

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

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

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

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

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