FAQ: 自己管理型 MongoDB 診断

このドキュメントでは、診断する一般的な質問と問題への回答を提供します。

必要な回答が見つからない場合は、の FAQ の完全なリストを確認するか、 MongoDB Communityに質問を投稿してください。

`mongod`予期せず実行中を停止したプロセスに関する情報はどこで取得できますか。

UNIX または UNIX ベースのプラットフォームでmongodが予期せずシャットダウンした場合、およびmongodがシャットダウンまたはエラーメッセージのログに失敗した場合は、システムログで MongoDB に関連するメッセージを確認してください。たとえば、 /var/log/messagesにあるログには、次のコマンドを使用します。

sudo grep mongod /var/log/messages
sudo grep score /var/log/messages

TCP`keepalive` 時間はMongoDBデプロイに影響しますか。

クライアントとサーバー間、またはシャーディングされたクラスターまたはレプリカセットのメンバー間の通信でネットワークタイムアウトやソケットエラーが発生した場合は、影響を受けるシステムのTCP キープアライブ値を確認します。

多くのオペレーティングシステムでは、この値はデフォルトで7200秒（2 時間）に設定されています。 MongoDB では通常、キープアライブ値が120分

MongoDB の配置でキープアライブに関連する問題が発生した場合は、影響を受けるすべてのシステムのキープアライブ値を変更する必要があります。これには、 mongodまたはmongosプロセスを実行しているすべてのマシンと、MongoDB に接続するクライアントプロセスをホストしているすべてのマシンが含まれます。

TCP キープアライブ値の調整：

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

macOS でキープアライブ設定を表示するには、次のコマンドを発行します。
```
sysctl net.inet.tcp.keepidle
```
値はミリ秒単位で測定されます。
net.inet.tcp.keepidleの値を変更するには、次のコマンドを使用して、ミリ秒単位で <value/<value> を指定します。
```
sudo sysctl net.inet.tcp.keepidle=<value>
```
この操作はシステムの再起動後は保持されず、システムを再起動するたびに設定する必要があります。この値を永続的に設定する手順については、オペレーティングシステムのドキュメントを参照してください。 keepalive の値が600000ミリ秒（ 10分）以上の場合、 mongodとmongosは keepalive を無視します。
注意
macOS 10.15 Catalina、Apple ではnet.inet.tcp.keepidleオプションの構成は許可されなくなりました。

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

TCP 再送信タイムアウトは MongoDB デプロイに影響しますか。

クライアントとサーバー間、またはシャーディングされたクラスターまたはレプリカセットのノード間でネットワークタイムアウトやソケットエラーが発生した場合は、影響を受けるシステムのtcp_retries2値を確認してください。

ほとんどの Linux オペレーティングシステムでは、この値はデフォルトで15に設定されていますが、Windows では5に設定されています。 MongoDB では、 tcp_retries2値が低いほど結果が改善し、 5 （12 秒）以下の順序になります。

MongoDB の配置で TCP 再送信タイムアウトに関連する問題が発生した場合は、影響を受けるすべてのシステムのtcp_retries2値（Windows ではTcpMaxDataRetransmission ）を変更してください。これには、 mongodまたはmongosプロセスを実行しているすべてのマシンと、MongoDB に接続するクライアントプロセスをホストしているすべてのマシンが含まれます。

TCP 再送信タイムアウトを調整する

ほとんどの Linux オペレーティングシステムで、 net.ipv4.tcp_retries2 sysctl 設定を調整して TCP 再送信を制御します。

注意

設定名にipv4が含まれていますが、 tcp_retries2設定は IPv4 と IPv6 の両方に適用されます。

現在の設定を表示するには、 sysctlコマンドを使用します。
sysctl net.ipv4.tcp_retries2
net.ipv4.tcp_retries = 15
実行時にtcp_retries2設定を変更するには、 sysctlコマンドを使用します。
```
sysctl -w net.ipv4.tcp_retries2=8
```
変更を永続的にするには、構成ファイルを編集します。
1. テキストエディターで/etc/sysctl.confを開きます。
  vi /etc/sysctl.conf
2. net.ipv4.tcp_retries2設定を構成します。
  net.ipv4.tcp_retries2 = 8
3. システムを再起動します。
システムでは新しいtcp_retries2設定が使用されるようになりました。

Windows では、 TcpMaxDataRetransmissionsパラメータを調整して TCP 再送信を制御します。

Windows でTcpMaxDataRetransmissions設定を表示するには、次のコマンドを実行します。
```
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v TcpMaxDataRetransmissions
```
デフォルトでは、このパラメータは設定されていません。値が存在しない場合に使用されるシステムのデフォルトは、 5再試行です。
TcpMaxDataRetransmissionsの値を変更するには、管理者Command Promptで次のコマンドを使用します。 <value>は整数です。
```
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v TcpMaxDataRetransmission /d <value>
```

MongoDB は多くの「接続を受け付けました」イベントをログに記録する理由

MongoDB ログに多数の接続メッセージと再接続メッセージが表示される場合、クライアントは MongoDB サーバーに頻繁に接続と切断を行っています。これは、リクエストプーリングを使用しないアプリケーション（たとえば、CVI など）の通常の動作です。接続オーバーヘッドを減らすために、Fastデータベース、Apache モジュール、またはその他の種類の永続アプリケーションサーバーの使用を検討してください。

これらの接続がパフォーマンスに影響を与えない場合は、ランタイムquietオプションまたはコマンドラインオプション--quietを使用して、これらのメッセージをログから非表示にできます。

MongoDB を監視するために利用できるツール

MongoDB Enterprise Advancedで利用可能なオンプレミスソリューションであるMongoDB Cloud ManagerとMongoDB Ops Managerには、実行中のMongoDB配置のデータを収集し、そのデータに基づいて可視化とアラートを提供するモニタリング機能が含まれています。

詳細については、 MongoDB Cloud ManagerのドキュメントとMongoDB Ops Managerのドキュメントも参照してください。

サードパーティツールの完全なリストは、「自己管理型 MongoDB 配置のモニタリング」ドキュメントの一部として利用できます。

WiredTiger ストレージエンジンのメモリ診断

ワーキングセットのサイズは RAM に収まる必要があるか？

No.

キャッシュに追加データをロードするのに十分なスペースがない場合、WiredTiger はキャッシュからページをエビクションして領域を解放します。

注意

storage.wiredTiger.engineConfig.cacheSizeGB は WiredTiger の内部キャッシュのサイズを制限します。オペレーティングシステムは、使用可能な空きメモリをファイルシステムキャッシュに使用するため、圧縮されたMongoDBデータファイルをメモリに保持できます。さらに、オペレーティングシステムは、空き RAM を使用して、ファイルシステムブロックとファイルシステムキャッシュをバッファリングします。

RAM の利用者増加に対応するためには、WiredTiger の内部キャッシュサイズを減らす必要がある場合があります。

デフォルトのWiredTiger内部キャッシュサイズの値は、マシンごとに 1 つの mongod インスタンスがあることを前提としています。1 台のマシンに複数のMongoDBインスタンスが存在する場合は、設定値を減らして他の mongod インスタンスに対応できるようにしてください。

システムで使用可能なすべての RAM にアクセスできないコンテナ（lxc、cgroups、Docker など）で mongod を実行する場合は、コンテナで使用可能な RAM の量よりも小さい値に storage.wiredTiger.engineConfig.cacheSizeGB を設定する必要があります。正確な量は、コンテナ内で実行中の他のプロセスによって異なります。memLimitMBを参照してください。

storage.wiredTiger.engineConfig.cacheSizeGB または storage.wiredTiger.engineConfig.cacheSizePct のいずれか 1 つだけを提供できます。

キャッシュとエビクションの統計を表示するには、 serverStatusコマンドを使用します。 wiredTiger.cacheフィールドには、キャッシュとエビクションに関する情報が保持されます。

...
"wiredTiger" : {
   ...
   "cache" : {
      "tracked dirty bytes in the cache" : <num>,
      "bytes currently in the cache" : <num>,
      "maximum bytes configured" : <num>,
      "bytes read into cache" :<num>,
      "bytes written from cache" : <num>,
      "pages evicted by application threads" : <num>,
      "checkpoint blocked page eviction" : <num>,
      "unmodified pages evicted" : <num>,
      "page split during eviction deepened the tree" : <num>,
      "modified pages evicted" : <num>,
      "pages selected for eviction unable to be evicted" : <num>,
      "pages evicted because they exceeded the in-memory maximum" : <num>,,
      "pages evicted because they had chains of deleted items" : <num>,
      "failed eviction of pages that exceeded the in-memory maximum" : <num>,
      "hazard pointer blocked page eviction" : <num>,
      "internal pages evicted" : <num>,
      "maximum page size at eviction" : <num>,
      "eviction server candidate queue empty when topping up" : <num>,
      "eviction server candidate queue not empty when topping up" : <num>,
      "eviction server evicting pages" : <num>,
      "eviction server populating queue, but not evicting pages" : <num>,
      "eviction server unable to reach eviction goal" : <num>,
      "pages split during eviction" : <num>,
      "pages walked for eviction" : <num>,
      "eviction worker thread evicting pages" : <num>,
      "in-memory page splits" : <num>,
      "percentage overhead" : <num>,
      "tracked dirty pages in the cache" : <num>,
      "pages currently held in the cache" : <num>,
      "pages read into cache" : <num>,
      "pages written from cache" : <num>,
   },
   ...

wiredTiger.cache.bytes currently in the cacheやwiredTiger.cache.tracked dirty bytes in the cacheなど、一部のキーキャッシュと削除統計の説明については、 wiredTiger.cacheを参照してください。

WiredTiger内部キャッシュのサイズを調整するには、--wiredTigerCacheSizeGB と storage.wiredTiger.engineConfig.cacheSizeGB を参照してください。WiredTiger の内部キャッシュサイズをデフォルト値より大きくしないようにしてください。ユースケースで内部キャッシュサイズを増やす必要がある場合は、--wiredTigerCacheSizePct と storage.wiredTiger.engineConfig.cacheSizePct を参照してください。

アプリケーションに必要な RAM の容量を計算するにはどうすればよいですか?

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 キャッシュや他のプロセスによって使用されていないすべての空きメモリを自動的に使用します。

注意

RAM の利用者増加に対応するためには、WiredTiger の内部キャッシュサイズを減らす必要がある場合があります。

storage.wiredTiger.engineConfig.cacheSizeGB または storage.wiredTiger.engineConfig.cacheSizePct のいずれか 1 つだけを提供できます。

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

シャーディングされたクラスターの診断

シャーディングされたクラスターを成功させるための最も重要な要素は次の 2 つです。

シャードキーは後でも変更できますが、スケーラビリティやパフォーマンスの問題を回避するために、シャードキーの選択を慎重にすることが重要になります。本番環境で発生する可能性のある特定の問題については、読み進める必要があります。

新しいシャーディングされたクラスターでは、すべてのデータが 1 つのシャードに残るのはなぜですか?

クラスターには、シャーディングのための十分なデータが必要です。シャーディングは、各シャードのチャンク数がほぼ同じになるまで、シャード間でチャンクを移行することで機能します。

デフォルトのチャンクサイズは 128 メガバイトです。 MongoDB は、クラスター内のチャンクのバランスが移行しきい値を超えるまで移行を開始しません。この動作は、不要なチャンクの移行を防ぐのに役立ち、クラスター全体のパフォーマンスを低下させる可能性があります。

シャーディングされたクラスターを配置したばかりの場合は、シャーディングを効果的にするのに十分なデータがあることを確認してください。 8 つを超える 128 メガバイトのチャンクを作成するのに十分なデータがない場合、すべてのデータは 1 つのシャード上に残ります。チャンクサイズの設定を減らすか、クラスターにデータを追加します。

関連する問題として、システムは挿入または更新でのみチャンクを分裂するため、シャーディングを構成し、挿入および更新操作を引き続き発行しないと、データベースはチャンクを作成しません。アプリケーションがデータを挿入するまで待つか、チャンクを手動で分割できます。

最後に、シャードキーの濃度が低い場合、MongoDB はデータ間で十分な分裂を作成できない可能性があります。

シャーディングされたクラスターでは、1 つのシャードが不釣り合いな量のトラフィックを受信するのはなぜですか?

状況によっては、単一のシャードまたはクラスターのサブセットがトラフィックとワークロードのうち不釣り合いな部分を受け取る場合があります。ほとんどの場合、これは書き込みスケーリングを効果的に許可していないシャードキーの結果です。

また、「ホットチャンク」があることも可能です。この場合、これらのチャンクの一部を分割して移行することで問題を解決できる場合があります。

このパターンを修正するには、別のシャードキーでコレクションを再シャーディングすることを検討する必要がある場合があります。

シャーディングされたクラスターのバランシングを妨げるものは何ですか。

シャーディングされたクラスターを配置したばかりの場合は、データが 1 つのシャードにデータが残っている新しいクラスターのトラブルシューティングの提案を検討してください。

クラスターが最初はバランシングされていたが、その後データの分散が不均一になった場合は、次の考えられる原因を考慮してください。

クラスターから大量のデータを削除または削除しました。データを追加した場合は、シャードキーに関するディストリビューションが異なる場合があります。
シャードキーの濃度が低いため、MongoDB はチャンクをこれ以上分割できません。
データセットの増大は、バランサーがクラスター全体にデータを分散できるよりも速くなります。これは一般的ではなく、通常は次の結果になります。
- データの増加速度を考慮すると、バランシングウィンドウが小さすぎる場合。
- より多くのデータ移行を必要とする書込み ( write) 操作が不均一に分散している。この問題を解決するには、別のシャードキーを選択する必要がある場合があります。
- シャード間のネットワーク接続が不十分なため、チャンクの移行が完了までの時間がかかりすぎる可能性があります。ネットワーク構成とシャード間の相互接続を調査します。

チャンクの移行がシャーディングされたクラスターのパフォーマンスに影響を与えるのはなぜですか?

移行がクラスターまたはアプリケーションのパフォーマンスに影響を与える場合は、影響の種類に応じて次のオプションを検討してください。

移行によってクラスターが散発的にのみ中断される場合は、バランシング期間を制限して、ピーク時間帯のバランシングアクティビティを防ぐことができます。データが再びバランスを失うのを防ぐのに十分な時間が残っていることを確認します。
バランサーが常にチャンクを移行し、クラスター全体のパフォーマンスが低下する場合。
- 移行のサイズを制限するには、チャンクサイズを減らす必要がある場合があります。
- クラスターが容量を超えている可能性があるため、負荷を分散するためにクラスターに1 つまたは 2 つのシャードを追加してみてください。

また、シャードキーによって、アプリケーションはすべての書き込みを単一のシャードに指示することもできます。この種のアクティビティパターンでは、バランサーが書き込みを行った後すぐにほとんどのデータを移行する必要がある場合があります。書込みスケーリングを改善するために、別のシャードキーを使用してコレクションを再シャーディングすることを検討する必要がある場合があります。

戻る

クラスターの監視

管理

TCPkeepalive 時間はMongoDBデプロイに影響しますか。