ApsaraDB for MongoDB:パラメータチューニングの推奨事項

operationProfiling.mode

• サポート対象のメジャーバージョン： 3.0 以降

• 再起動が必要： はい

• デフォルト値： off

• 機能： クエリプロファイラーのプロファイリングレベルを指定します。

• 問題点：

  • このパラメーターを all または slowOp に設定すると、生成される大量の低速クエリログによってインスタンスのパフォーマンスが低下し、分析が複雑になるおそれがあります。

  • クエリプロファイラーを無効にし忘れると、データベースに system.profile コレクションが出現し、一部のユーザーが混乱することがあります。

  • 一部のユーザーは、スロークエリログを生成するには、このパラメーターを slowOp に設定する必要があると誤解しています。

• 推奨事項：

  デフォルト値を維持してください。スロークエリログは、クエリプロファイラーのパフォーマンスオーバーヘッドなしで、同様の分析情報を提供します。必要な場合にのみこの機能を有効にし、分析完了後は速やかに無効にしてください。データベースプロファイラーの詳細については、「MongoDB 公式ドキュメント」をご参照ください。

operationProfiling.slowOpThresholdMs

• サポート対象のメジャーバージョン： 3.0 以降

• 再起動が必要： いいえ

• デフォルト値： 100

• 機能： クエリがスロークエリと見なされるしきい値をミリ秒単位で定義します。

• 問題点：

  • 値を低く設定しすぎると、大量のスロークエリログと監査ログが生成され、ノイズが発生して分析が複雑になる可能性があります。

  • 値を高く設定しすぎると、多くのスロークエリがログに記録されず、分析プロセスが妨げられる可能性があります。

• 推奨事項： ワークロードに応じてしきい値を調整してください。重要なクエリの平均レイテンシーよりもわずかに高い値に設定することを推奨します。例：

  • レイテンシーに敏感なアプリケーションで、通常のクエリが約 30 ms かかる場合、一時的なパフォーマンス変動を分析するために、しきい値を 50 に下げることを検討してください。

  • 分析処理が多いアプリケーションで、クエリが通常 300 ms から 400 ms かかる場合、ログのノイズを減らすために、しきい値を 500 ms に上げることを検討してください。

replication.oplogGlobalIdEnabled

• サポート対象のメジャーバージョン： 4.0 以降

• 再起動が必要： はい

• デフォルト値： false

• この Alibaba Cloud のカスタムパラメーターは、Data Transmission Service (DTS) や mongoShake などのツールを使用した双方向同期をサポートするために、oplog でグローバル ID (GID) を有効にします。GID は、これらの構成における循環レプリケーションの問題を防ぎます。

• 推奨事項： 双方向同期が必要な場合にのみ、このパラメーターを有効にしてください。この変更にはインスタンスの再起動が必要なため、オフピーク時間に適用することを推奨します。

replication.oplogSizeMB

• サポート対象のメジャーバージョン： 3.0 以降

• 再起動が必要： いいえ

• デフォルト値： インスタンスのディスク領域の 10%。たとえば、インスタンスのディスク領域が 500 GB の場合、初期 oplogSizeMB は 51,200 (50 GB) です。

• 機能： レプリケーションログを格納する oplog コレクションの最大論理サイズを指定します。

• 問題点： 値が低すぎると、セカンダリノードが遅れて RECOVERING 状態になる可能性があります。また、ログバックアップにギャップが生じ、ポイントインタイムリカバリができなくなる可能性があります。

• 推奨事項： デフォルト値を維持してください。減らさないでください。必要な場合にのみ増やしてください。データ量は少ないが更新頻度が高く、oplog エントリが急速に生成されるワークロードの場合、値を増やすことを検討してください。oplogSizeMB を大きくすることで、oplog がより長い時間ウィンドウをカバーでき、ギャップを防ぐことができます。ベストプラクティスとして、oplog サイズは少なくとも 1 時間分の oplog レコードを保持できる大きさにする必要があります。

setParameter.cursorTimeoutMillis

• サポート対象のメジャーバージョン： 3.0 以降

• 再起動が必要： いいえ

• デフォルト値： 600000 (10 分)

• 機能： アイドルカーソルのタイムアウトをミリ秒単位で指定します。MongoDB は、このしきい値よりも長くアイドル状態のカーソルを自動的にクリーンアップします。

• 問題点： 期限切れでクリーンアップされたカーソルにアクセスしようとすると、クライアントは次の形式のエラーを受け取ります：

  Message: "cursor id xxxxxxx not found"
  ErrorCode: CursorNotFound(43)

• 推奨事項： この値を増やすことは推奨しません。アイドルカーソルのリソースオーバーヘッドを減らすために、値を減らす (たとえば 300000 に) ことができます。すべてのシナリオにおいて、アプリケーションは長時間アイドル状態のカーソルを作成しないようにする必要があります。

setParameter.flowControlTargetLagSeconds

• サポート対象のメジャーバージョン： 4.2 以降

• 再起動が必要： いいえ

• デフォルト値： 10

• 機能： フロー制御 メカニズムをトリガーするしきい値を指定します。フロー制御の目的は、マジョリティコミットポイントが大きく遅れないようにすることです。

• 問題点： リクエストのレイテンシーが大幅に増加し、次の例のようなスロークエリログが表示されます。durationMillis の値が flowControl.timeAcquiringMicros とほぼ等しい場合、フロー制御メカニズムがリクエストを遅延させたことを示します。

  {
    "t": {
      "$date": "2024-04-25T13:28:45.840+08:00"
    },
    "s": "I",
    "c": "WRITE",
    "id": 51803,
    "ctx": "conn199253",
    "msg": "Slow query",
    "attr": {
      "type": "update",
      "ns": "xxx.xxxxx",
      "command": ...,
      "planSummary": "IDHACK",
      "totalOplogSlotDurationMicros": 61,
      "keysExamined": 1,
      "docsExamined": 1,
      "nMatched": 1,
      "nModified": 1,
      "nUpserted": 0,
      "keysInserted": 0,
      "keysDeleted": 0,
      "numYields": 0,
      "locks": ...,
      "flowControl": {
        "acquireCount": 1,
        "acquireWaitCount": 1,
        "timeAcquiringMicros": 959000
      },
      "readConcern": {
        "level": "local",
        "provenance": "implicitDefault"
      },
      "storage": {},
      "cpuNanos": 258845,
      "remote": "172.16.6.38:52368",
      "durationMillis": 959
    }
  }
  

• 推奨事項： この値を増やして、フロー制御メカニズムの感度を下げることができます。値を増やした後もリクエストが頻繁にスロットリングされる場合、レプリケーションにパフォーマンスのボトルネックがある可能性があります。この場合、さらなる分析を行い、インスタンス構成のアップグレードやライトコンサーンを majority に設定するなど、他の対策を講じる必要があります。

setParameter.oplogFetcherUsesExhaust

• サポート対象のメジャーバージョン： 4.4 以降

• 再起動が必要： はい

• デフォルト値： true

• 機能： ストリーミングレプリケーション を有効にするかどうかを指定します。この機能を無効にすると、レプリケーションは以前のバージョンのプルベース方式に戻ります。この方式では、セカンダリノードが同期元から oplog エントリのバッチをリクエストするため、バッチごとにネットワークラウンドトリップが必要になります。

• 問題点： 一部のシナリオでは、ストリーミングレプリケーションメカニズムが追加のパフォーマンスとネットワーク帯域幅のオーバーヘッドをもたらす可能性があります。

• 推奨: この設定は変更しないことをお勧めします。ストリームレプリケーションにより、高負荷および高レイテンシーのネットワーク環境でのレプリケーションのレイテンシーを低減できます。また、writeConcern が {w:1} に設定されている場合にプライマリノードが予期せずダウンした際の書き込み損失のリスクを低減し、{w:majority} や {w:>1} など、プライマリ-セカンダリ間のレプリケーションに依存する他の writeConcern 設定の書き込みレイテンシーも低減します。

setParameter.maxTransactionLockRequestTimeoutMillis

• サポート対象のメジャーバージョン： 4.0 以降

• 再起動が必要： いいえ

• デフォルト値： 5

• 機能： トランザクションがロックを取得するためのタイムアウトをミリ秒単位で指定します。トランザクション内の操作がこの期間内に必要なロックを取得できない場合、トランザクションは自動的に中止されます。

• 問題点： 次のロックタイムアウトエラーメッセージがログに表示されるか、クライアントに返されます。最新のドライバーは TransientTransactionError で自動的に再試行する可能性があるため、エラーはログにのみ表示され、クライアントには認識されない場合があります。

  Message: "Unable to acquire lock '{8442595743001781021: Database, 1525066715360699165}' within a max lock request timeout of '5ms' milliseconds."
  ErrorCode: LockTimeout(24)

• 推奨事項： クライアントがこのエラーに頻繁に遭遇する場合は、この値を増やすことを検討してください。これにより、一時的なロック失敗による中止を軽減できますが、デッドロックに関与するトランザクションの終了が遅れる可能性があります。問題が解決しない場合は、値をさらに増やすのではなく、アプリケーションロジックを最適化してください。たとえば、同じドキュメントへの同時変更を避け、長時間実行されるタスク (DDL や最適化されていないクエリなど) がロックを長時間保持する可能性がある操作を見直してください。

setParameter.replWriterThreadCount

• サポート対象のメジャーバージョン： 3.2 以降

• 再起動が必要： はい

• デフォルト値： 16

• 機能： 並列レプリケーションの最大スレッド数を指定します。有効な最大スレッド数は、インスタンスの CPU コア数の 2 倍です。

• 問題点： 極端な場合、セカンダリノードのレプリケーションラグが継続的に増加します。

• 推奨事項： ほとんどの場合、この設定を変更しないことを推奨します。特別な状況では、Alibaba Cloud サポートエンジニアの指導の下でのみ、このパラメーターを調整してください。

setParameter.tcmallocAggressiveMemoryDecommit

• サポート対象のメジャーバージョン： 4.2 以降

• 再起動が必要： いいえ

• デフォルト値： 0 (TCMalloc アグレッシブメモリデコミットを無効にします)

• 機能： MongoDB は TCMalloc メモリアロケーターを使用します。このパラメーターは、TCMalloc のアグレッシブデコミットポリシーを制御します。このポリシーは、隣接する空きメモリブロックを積極的にマージし、オペレーティングシステムに返します。

• 問題点：

  • クエリによるメモリ消費が高いため、メモリを十分に迅速に再利用できず、mongod ノードでメモリ不足 (OOM) エラーが発生します。

  • インスタンスの実行に伴い、ヒープメモリの断片化が増加し、メモリ使用率が 80% を超えて着実に上昇します。

• 推奨事項： ほとんどの場合、この設定を変更しないことを推奨します。メモリ関連の問題が発生した場合は、オフピーク時間にこのパラメーターの調整を検討してください。

setParameter.transactionLifetimeLimitSeconds

• サポート対象のメジャーバージョン： 4.0 以降

• 再起動が必要： いいえ

• デフォルト値： 60

• 機能： トランザクションの有効期間を秒単位で指定します。トランザクションの合計実行時間がこの制限を超えると、期限切れとしてマークされ、定期的なバックグラウンドクリーンアップスレッドによって中止されます。

• 問題点： クライアントは次の形式のエラーを受け取ります：

  Message: "Aborting transaction with txnNumber xxx on session with lsid xxxxxxxxxx because it has been running for longer than 'transactionLifetimeLimitSeconds'"

• 推奨事項: この値は小さくできますが (たとえば 30 に)、大きくすることは推奨されません。長時間実行される未コミットのトランザクションは、WiredTiger ストレージエンジンのキャッシュに大きな負荷をかける可能性があります。過負荷のキャッシュは、データベースのフリーズ、リクエストレイテンシーの急激な増加、CPU 使用率の最大化など、より多くの問題を引き起こすことが多く、サービスの品質を低下させる可能性があります。アプリケーションでは、可能な限り長時間実行されるトランザクションを避ける必要があります。タイムアウトの問題を解決するには、設定された時間制限内に完了できるように、トランザクションをより小さな部分に分割する必要があります。また、トランザクション内で高速なデータアクセスを実現するために、クエリが最適化され、適切なインデックスカバレッジがあることを確認する必要もあります。

トランザクションのベストプラクティスの詳細については、「トランザクションとRead/Write Concern」をご参照ください。

storage.oplogMinRetentionHours

• サポート対象のメジャーバージョン： 4.4 以降

• 再起動が必要： いいえ

• デフォルト値: 0 (値 0 は、このパラメーターが無効になり、oplog サイズが replication.oplogSizeMB パラメーターによって完全に制御されることを示します。)

• 機能： oplog の最小保持期間を時間単位で指定します。

• 問題点：

  • 値を高く設定しすぎると、oplog が過剰なディスク領域を消費する可能性があります。

  • 一部のユーザーは、このパラメーターを設定したことを忘れ、インスタンスのディスク領域使用量の変動に混乱する可能性があります。

• 推奨事項： 比較的安定したワークロードの場合は、デフォルト値を維持してください。書き込み操作に大きな変動が生じる可能性のあるワークロードの場合は、このパラメーターを 1.0 より大きい浮動小数点数に設定することを推奨します。このパラメーターを設定する際は、ディスクの満杯によって引き起こされる他の問題を回避するために、潜在的なディスク領域消費も評価する必要があります。

storage.wiredTiger.collectionConfig.blockCompressor

• サポート対象のメジャーバージョン： 3.0 以降

• 再起動が必要： はい

• デフォルト値： snappy

• 機能: コレクションデータのストレージ圧縮アルゴリズムを指定します。この設定は、新しく作成されたテーブルにのみ適用され、既存のテーブルには影響しません。現在サポートされているアルゴリズムは、圧縮なし、 snappy、 zlib、 zstd です。 zstd アルゴリズムは、バージョン 4.2 以降でのみサポートされています。

• 推奨事項：必要に応じて変更してください。圧縮アルゴリズムが異なれば、パフォーマンスも異なります。圧縮アルゴリズムによっては、圧縮率は高くなりますが、その分、圧縮および解凍中の CPU オーバーヘッドが大きくなります。圧縮アルゴリズム間の比較は、お客様自身のテスト結果に基づいて行う必要があります。インスタンスが主にコールドデータの保存に使用される場合は、このパラメーターを zstd に変更して、より高い圧縮率を実現することを検討してください。

  説明

  コレクションごとに異なる圧縮アルゴリズムを使用するには、関連オプションを指定してcreateCollection コマンドを明示的に使用する必要があります。詳細については、「MongoDB 公式ドキュメント」をご参照ください。

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

• サポート対象のメジャーバージョン： 4.4 以降

• 再起動が必要： いいえ

• デフォルト値： 300 (5 分)

• 機能： WiredTiger ストレージエンジンがスナップショット履歴を保持するウィンドウサイズを秒単位で指定します。値が 0 の場合、スナップショット履歴ウィンドウは無効になります。このパラメーターは主に、特定の atClusterTime での読み取りをサポートするために使用されます。

• 問題点： このパラメーターは、特に同じドキュメントへの頻繁な更新があるシナリオで、WiredTiger キャッシュへの負荷を増加させる可能性があります。

• 推奨事項： ほとんどの場合、この設定を変更しないことを推奨します。

  • アプリケーションが read atClusterTime 機能を使用しない場合は、このパラメーターを 0 に設定して、わずかなパフォーマンス向上を得ることができます。

  • アプリケーションが 5 分より古い履歴スナップショットデータを読み取る必要がある場合は、この値を増やすことができます。ただし、これにより追加のメモリ消費とパフォーマンスオーバーヘッドが発生することに注意してください。

  説明

  このパラメーターの値が低く、履歴スナップショットの読み取り時に古すぎる時間を指定した場合、SnapshotTooOld エラーが返されます。

rsconf.chainingAllowed

• サポート対象のメジャーバージョン： 4.0 以降

• 再起動が必要： いいえ

• デフォルト値： true

• 機能： レプリカセットでチェーンレプリケーションを許可するかどうかを指定します。

• 問題点：

  • チェーンレプリケーションを無効にすると、CPU 使用率やネットワークトラフィックなど、プライマリノードの負荷が増加する可能性があります。

  • チェーンレプリケーションを有効にすると、セカンダリノードのレプリケーションラグが増加する可能性があります。

• 推奨事項：

  • 4 ノード以下のレプリカセットの場合： ニーズに応じてチェーンレプリケーションを有効または無効にできます。

  • ノード数が多い (5 以上) 場合、writeConcern が {w:majority} として設定されている場合にのみ、プライマリノードの負荷とインスタンスのパフォーマンスの間でさらなるトレードオフを行う必要があります。チェーンレプリケーションを無効にすると、書き込みパフォーマンスは向上しますが、プライマリノードへの負荷も大幅に増加します。

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

• サポート対象のメジャーバージョン： 4.2 以降

• 再起動が必要： いいえ

• デフォルト値： 104,857,600 B (100 MB)

• 機能: $push および $addToSet 演算子の最大メモリ使用量を制限します。

• 症状: $push または $addToSet を含む特定の SQL 文が実行に失敗し、次のエラーメッセージが返されます。

  "errMsg": "$push used too much memory and cannot spill to disk. Memory limit: 104857600... 

• 推奨事項： ほとんどの場合、この設定を変更しないことを推奨します。特定のクエリを実行する際に上記のエラーが発生した場合は、値を増やすことを検討できます。ただし、この値を高く設定しすぎると、mongod ノードでメモリ不足 (OOM) エラーが発生する可能性があることに注意してください。

setParameter.migrateCloneInsertionBatchSize

• サポート対象のメジャーバージョン：4.0 以降

• 再起動の要否：不要

• デフォルト値：0 (16 MB のドキュメントサイズによる制限を受けます)

• 機能：チャンク移行のクローニングステップにおける 1 バッチあたりの最大ドキュメント数を指定します。

• 問題：チャンク移行により、シャードのパフォーマンスが変動する可能性があります。

• 推奨事項：ほとんどの場合、この設定は変更しないことを推奨します。チャンク移行が原因で、バランシング中にシャードクラスターインスタンスのパフォーマンスが変動する場合は、このパラメーターを固定のバッチサイズに設定することを検討してください。

setParameter.rangeDeleterBatchDelayMS

• サポート対象のメジャーバージョン：4.0 以降

• 再起動の要否：不要

• デフォルト値：20

• 機能：チャンク移行のクリーンアップステップにおけるバッチ削除の間隔を指定します。この設定は、孤立ドキュメントをクリーンアップする cleanupOrphaned コマンドにも影響します。単位はミリ秒です。

• 問題：

  • 一部のシナリオでは、チャンク移行後のドキュメントの非同期削除により、CPU 使用率が急増する可能性があります。

  • 値を高く設定しすぎると、ドキュメントが時間内に削除されないため、孤立ドキュメントになる可能性があります。また、削除対象のドキュメント数が多すぎる場合にタイムアウトが発生し、以下のエラーログが出力されることがあります：

    Message: "OperationFailed: Data transfer error: ExceededTimeLimit: Failed to delete orphaned <db>.<collection> range [xxxxxx,xxxxx] :: caused by :: operation exceeded time limit"

• 推奨事項：通常、調整は不要です。ドキュメントの非同期削除が原因で、バランシング中にシャードクラスターインスタンスの CPU 使用率が急増する場合は、このパラメーターを (例：200) に増やすことができます。

setParameter.rangeDeleterBatchSize

• サポート対象のメジャーバージョン：4.0 以降

• 再起動の要否：不要

• デフォルト値：0 (妥当なバッチサイズが自動的に選択されます。通常は 128 です)

• 機能：チャンク移行のクリーンアップステップにおける非同期削除時の、1 バッチあたりの最大ドキュメント数を指定します。

• 問題：一部のシナリオでは、チャンク移行後のドキュメントの非同期削除により、CPU 使用率が急増する可能性があります。

• 推奨事項：ほとんどの場合、この設定は変更しないことを推奨します。ドキュメントの非同期削除が原因で、バランシング中にシャードクラスターインスタンスの CPU 使用率が急増する場合は、このパラメーターを固定のバッチサイズに設定することを検討してください。

setParameter.receiveChunkWaitForRangeDeleterTimeoutMS

• サポート対象のメジャーバージョン：4.4 以降

• 再起動の要否：不要

• デフォルト値：10000 (10 秒)

• 機能：チャンク移行の前に、孤立ドキュメントが削除されるまで待機するタイムアウト時間 (ミリ秒) を指定します。

• 問題：バランサーの実行中に、以下のようなタイムアウトエラーログが出力される場合があります：

  ExceededTimeLimit: Failed to delete orphaned <db.collection> range [{ <shard_key>: MinKey }, { <shard_key>: -9186000910690368367 }) :: caused by :: operation exceeded time limit

• 推奨事項：ほとんどの場合、この設定は変更しないことを推奨します。上記のエラーが発生した場合は、この値を増やすことで moveChunk 操作が孤立ドキュメントの削除完了をより長く待機できるようになり、このようなタイムアウトエラーを回避できます。

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

• サポート対象のメジャーバージョン： 4.4 以降

• 再起動が必要： いいえ

• デフォルト値： 300 (5 分)

• 機能： WiredTiger ストレージエンジンがスナップショット履歴を保持するウィンドウサイズを秒単位で指定します。値が 0 の場合、スナップショット履歴ウィンドウは無効になります。このパラメーターは主に、特定の atClusterTime での読み取りをサポートするために使用されます。

• 問題点： このパラメーターは、特に同じドキュメントへの頻繁な更新があるシナリオで、WiredTiger キャッシュへの負荷を増加させる可能性があります。

• 推奨事項： ほとんどの場合、この設定を変更しないことを推奨します。

  • アプリケーションが read atClusterTime 機能を使用しない場合は、このパラメーターを 0 に設定して、わずかなパフォーマンス向上を得ることができます。

  • アプリケーションが 5 分より古い履歴スナップショットデータを読み取る必要がある場合は、この値を増やすことができます。ただし、これにより追加のメモリ消費とパフォーマンスオーバーヘッドが発生することに注意してください。

  説明

  このパラメーターの値が低く、履歴スナップショットの読み取り時に古すぎる時間を指定した場合、SnapshotTooOld エラーが返されます。

rsconf.chainingAllowed

• サポート対象のメジャーバージョン：4.0 以降

• 再起動の要否：不要

• デフォルト値：true

• 機能：シャードでチェーンレプリケーションを許可するかどうかを指定します。

• 問題：

  • チェーンレプリケーションを無効にすると、CPU 使用率やネットワークトラフィックなど、プライマリーノードの負荷が増加する可能性があります。

  • チェーンレプリケーションを有効にすると、セカンダリーノードのレプリケーションラグが増加する可能性があります。

• 推奨事項：

  • ノード数が 4 以下のシャード：要件に応じて、チェーンレプリケーションを有効または無効にできます。

  • ノード数が多い (5 以上) 場合で、writeConcern を {w:majority} に設定している場合は、プライマリーノードの負荷とインスタンスのパフォーマンスの間でトレードオフを検討する必要があります。チェーンレプリケーションを無効にすると書き込みパフォーマンスが向上しますが、プライマリーノードの負荷も大幅に増加します。

setParameter.periodicNoopIntervalSecs

• サポート対象のメジャーバージョン：4.2 以降

• 再起動の要否：必要

• デフォルト値：10

• 機能：noop 書き込みの間隔 (秒) を指定します。

• 問題：Change Streams を使用している場合、書き込みアクティビティが低いシャードが、変更の集約時に mongos のボトルネックになることがあります。これにより、約 10 秒の Change Stream 遅延が発生する可能性があります。

• 推奨事項：ほとんどの場合、この設定は変更しないことを推奨します。Change Streams の使用時に上記の遅延が発生する場合は、このパラメーターを 1 に下げることを検討してください。これにより、noop 書き込みの頻度が増え、単一シャードでの書き込みアクティビティの低さが原因で発生する Change Stream の消費遅延を防止できます。

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

• サポート対象のメジャーバージョン： 4.2 以降

• 再起動が必要： いいえ

• デフォルト値： 104,857,600 B (100 MB)

• 機能: $push および $addToSet 演算子の最大メモリ使用量を制限します。

• 症状: $push または $addToSet を含む特定の SQL 文が実行に失敗し、次のエラーメッセージが返されます。

  "errMsg": "$push used too much memory and cannot spill to disk. Memory limit: 104857600... 

• 推奨事項： ほとんどの場合、この設定を変更しないことを推奨します。特定のクエリを実行する際に上記のエラーが発生した場合は、値を増やすことを検討できます。ただし、この値を高く設定しすぎると、mongod ノードでメモリ不足 (OOM) エラーが発生する可能性があることに注意してください。

operationProfiling.slowOpThresholdMs

• サポートされているメジャーバージョン： 3.0 以降

• 再起動が必要： いいえ

• デフォルト値： 100

• 機能： クエリをスロークエリと見なすためのしきい値 (ミリ秒) を定義します。

• 問題：

  • 値を低く設定しすぎると、大量のスロークエリログと監査ログが生成され、ノイズが増えて分析が複雑になる可能性があります。

  • 値を高く設定しすぎると、多くのスロークエリがログに記録されなくなり、分析を妨げる可能性があります。

• 推奨事項： ワークロードに基づいてしきい値を調整してください。重要なクエリの平均レイテンシーよりも少し高い値に設定することを推奨します。例：

  • レイテンシーに敏感なアプリケーションで、一般的なクエリが約 30 ms かかる場合は、一時的なパフォーマンスの変動の分析に役立つよう、しきい値を 50 に下げることを検討してください。

  • 分析処理が中心のアプリケーションで、一般的なクエリが 300 ms ～ 400 ms かかる場合は、ログノイズを減らすため、しきい値を 500 ms に上げることを検討してください。

setParameter.ShardingTaskExecutorPoolMaxConnecting

• サポートされているメジャーバージョン： 3.6 以降

• 再起動が必要：

  • バージョン 3.6 および 4.0： はい

  • バージョン 4.2 以降： いいえ

• デフォルト値： 2

• 機能： mongos ノードの TaskExecutor 接続プールが初期化時に確立できる同時接続の最大数を指定します。mongos からシャードノードへの接続作成レートを制御します。

• 問題： この値が高すぎると、一度に多くの接続が作成され、mongos ノードの CPU 使用率が急上昇する可能性があります。

• 推奨事項： この設定は変更しないことを推奨します。

setParameter.ShardingTaskExecutorPoolMaxSize

• サポートされているメジャーバージョン： 3.6 以降

• 再起動が必要：

  • バージョン 3.6 および 4.0： はい

  • バージョン 4.2 以降： いいえ

• デフォルト値： 2^64-1 (64 ビット整数の最大値)

• 機能： mongos ノード上の各 TaskExecutor 接続プールにおける接続数の上限を指定します。

• 推奨事項： 調整は不要です。このパラメーターを設定することで、mongos からシャードへの接続プールサイズを制限できますが、値を低く設定しすぎないことを推奨します。値が小さすぎると、接続プールが枯渇した際に mongos のリクエストがブロックされる可能性があります。

setParameter.ShardingTaskExecutorPoolMinSize

• サポートされているメジャーバージョン： 3.6 以降

• 再起動が必要：

  • バージョン 3.6 および 4.0： はい

  • バージョン 4.2 以降： いいえ

• デフォルト値： 1

• 機能： mongos ノード上の各 TaskExecutor 接続プールにおける最小接続数を指定します。

• 問題： リクエストが急増すると、mongos ノードの TaskExecutor 接続プールが一度に多数の新規接続を作成することがあり、CPU 使用率の急上昇などの問題を引き起こす可能性があります。

• 推奨事項： [10,50] の範囲で妥当な値に設定してください。具体的な値は、シャードインスタンスのトポロジー (シャード数、および各シャードのノード数) に依存します。mongos は、シャードに対するこれらのアイドル接続を維持するために、わずかなリソースオーバーヘッドが発生する点に注意してください。

setParameter.cursorTimeoutMillis

• サポートされているメジャーバージョン： 3.0 以降

• 再起動が必要： いいえ

• デフォルト値： 600000 (10 分)

• 機能： アイドルカーソルの有効期限のしきい値 (ミリ秒) を指定します。MongoDB は、このしきい値よりも長くアイドル状態であったカーソルを自動的にクリーンアップします。

• 問題： 期限切れとなってクリーンアップされたカーソルにアクセスしようとすると、クライアントは次の形式のエラーを受け取ります：

  Message: "cursor id xxxxxxx not found"
  ErrorCode: CursorNotFound(43)

• 推奨事項： この値を増やすことは推奨しません。アイドルカーソルのリソースオーバーヘッドを減らすため、値を減らすことができます (例： 300000)。すべてのシナリオで、アプリケーションは長時間アイドル状態となるカーソルを作成しないようにしてください。