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

operationProfiling.mode

• 適用可能なメジャーバージョン：3.0 以降

• 変更後の再起動要否：要

• デフォルト値：off

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

• 症状：

  • このパラメーターを all または slowOp に設定し、多くのスロークエリログが生成されると、インスタンスのパフォーマンスが低下する可能性があります。

  • 一部のユーザーはクエリプロファイラーを無効にし忘れて、データベースの 1 つに system.profile コレクションが存在することに気づく場合があります。

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

• 推奨事項：

  デフォルト値を維持することを推奨します。クエリプロファイラーを有効にすると、インスタンスのパフォーマンスが低下する可能性があり、通常、スロークエリログで分析に十分な情報が得られます。プロファイラーは必要な場合にのみ有効にし、分析が完了したら速やかに無効にしてください。Database Profiler の詳細については、公式ドキュメントをご参照ください。

operationProfiling.slowOpThresholdMs

• 適用可能なメジャーバージョン：3.0 以降

• 変更後の再起動要否：不要

• デフォルト値：100

• 機能：スロークエリのしきい値を定義します。

• 症状：

  • 値が小さすぎると、多くのスロークエリログと監査ログが生成されます。これによりノイズが発生し、スロークエリの分析が複雑になります。

  • 値が大きすぎると、多くのスロークエリがログに記録されません。これにより、スロークエリの分析プロセスが複雑になります。

• 推奨事項：ビジネスニーズに基づいてしきい値を調整します。このパラメーターを、コアとなるクエリの平均実行時間よりわずかに高い値に設定します。例：

  • クエリのレイテンシに敏感で、典型的なクエリ時間が約 30 ms のビジネスの場合、このパラメーターを 50 に下げて、一時的なスロークエリのジッターを分析するのに役立てることができます。

  • 分析クエリが多く、典型的なクエリ時間が 300 ms から 400 ms のビジネスの場合、このパラメーターを 500 ms に増やして、スローログのノイズを減らすことができます。

replication.oplogGlobalIdEnabled

• 適用可能なメジャーバージョン：4.0 以降

• 変更後の再起動要否：要

• デフォルト値：false

• 機能：oplog でグローバル ID (GID) を有効にして、DTS または mongoShake との双方向同期をサポートするかどうかを指定します。これは自己開発のパラメーターです。GID は、双方向同期における循環同期の問題を解決するために使用されます。

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

replication.oplogSizeMB

• 適用可能なメジャーバージョン：3.0 以降

• 変更後の再起動要否：不要

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

• 機能：論理的な同期ログを格納する oplog コレクションの最大論理サイズを指定します。

• 症状：この値が小さすぎると、セカンダリノードが追いつけなくなり、RECOVERING 状態になる可能性があります。ログバックアップで oplog レコードが欠落し、ポイントインタイムリストアができなくなるギャップが生じることもあります。

• 推奨事項：デフォルト値を維持してください。値を減らさないでください。必要に応じて増やしてください。データ量は少ないが更新が頻繁で、oplog エントリが迅速に生成されるワークロードの場合は、値を増やすことを検討してください。`oplogSizeMB` を大きくすると、oplog がより長い期間をカバーできるようになり、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 エントリのバッチを取得し、応答を待ちます。これは、oplog エントリの各バッチに 1 回のネットワークラウンドトリップが必要であることを意味します。

• 症状：一部のシナリオでは、ストリームレプリケーションメカニズムが余分なパフォーマンスオーバーヘッドとネットワーク帯域幅オーバーヘッドを引き起こす可能性があります。

• 推奨事項：このパラメーターは調整しないでください。ストリームレプリケーションは、高負荷および高レイテンシのネットワーク環境でのレプリケーションの遅延を削減できます。また、ライトコンサーンが {w:1} のプライマリノードが予期せずダウンした場合の書き込みによるデータ損失のリスクを低減できます。さらに、{w:majority} や {w:>1} など、プライマリ-セカンダリレプリケーションに依存する他のライトコンサーンの書き込みレイテンシを削減することもできます。

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 倍です。

• 症状：極端なシナリオでは、プライマリ-セカンダリ同期が遅延し、セカンダリノードのレプリケーションの遅延 (lag) が継続的に増加する可能性があります。

• 推奨事項：ほとんどの場合、このパラメーターを調整する必要はありません。特別な場合には、Alibaba Cloud のエンジニアの推奨に基づいて調整してください。

setParameter.tcmallocAggressiveMemoryDecommit

• 適用可能なメジャーバージョン：4.2 以降

• 変更後の再起動要否：不要

• デフォルト値：0 (TCMalloc の積極的なデコミットを無効にする)

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

• 症状：

  • クエリによる高いメモリ消費にメモリの解放が追いつかず、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 使用率の飽和など、さらなる問題を引き起こし、ビジネスに悪影響を及ぼす可能性があります。すべてのシナリオで長時間トランザクションを避けてください。タイムアウトの問題を解決するには、トランザクションを、設定された時間制限内に完了できる小さな部分に分割します。また、クエリを最適化し、トランザクション内で高速なデータアクセスができるように、適切なインデックスカバレッジを確保する必要があります。

トランザクションの使用に関するベストプラクティスの詳細については、「トランザクションとリード/ライトコンサーン」をご参照ください。

storage.oplogMinRetentionHours

• 適用可能なメジャーバージョン：4.4 以降

• 変更後の再起動要否：不要

• デフォルト値：0 (このパラメーターは無効です。oplog サイズは replication.oplogSizeMB パラメーターによって完全に制御されます。)

• 機能：論理的な同期ログを格納する oplog コレクションの最小保持期間を指定します。

• 症状：

  • この値が大きすぎると、oplog コレクションが過剰なディスク領域を占有します。

  • 一部のユーザーは、このパラメーターを設定したことを忘れ、インスタンスのディスク領域の変動に戸惑うことがあります。

• 推奨事項：比較的安定したワークロードの場合は、デフォルト値を維持してください。書き込み操作に大きな変動がある可能性のあるワークロードの場合は、このパラメーターを 1.0 より大きい浮動小数点数に設定してください。このパラメーターを設定する際は、ディスクフルロックをトリガーして他の問題を引き起こさないように、潜在的なディスク領域の使用量も評価してください。

storage.wiredTiger.collectionConfig.blockCompressor

• 適用可能なメジャーバージョン：3.0 以降

• 変更後の再起動要否：要

• デフォルト値：snappy

• 機能：コレクションデータのストレージ圧縮アルゴリズムを設定します。この変更は新しいコレクションにのみ影響します。既存のコレクションは影響を受けません。サポートされているアルゴリズムには、`none` (圧縮なし)、snappy、zlib、zstd があります。zstd アルゴリズムは MongoDB 4.2 以降でのみサポートされています。

• 推奨事項：必要に応じてこのパラメーターを変更してください。圧縮アルゴリズムごとにパフォーマンス特性が異なります。一部は高い圧縮率を提供しますが、圧縮と展開のための CPU オーバーヘッドが大きくなります。圧縮アルゴリズム間の実際の比較は、ご自身のテスト結果に基づいて行う必要があります。インスタンスが主にコールドデータの保存に使用される場合は、このパラメーターを zstd に変更して、より高い圧縮率を達成することを検討してください。

  説明

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

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

• 適用可能なメジャーバージョン：4.4 以降

• 変更後の再起動要否：不要

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

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

• 症状：このパラメーターは、特に同じドキュメントが頻繁に更新されるシナリオで、WiredTiger キャッシュ (WT キャッシュ) に負荷をかける可能性があります。

• 推奨事項：ほとんどの場合、調整は不要です。

  • ビジネスで履歴スナップショットの読み取り (read atClusterTime) 機能を使用しない場合は、このパラメーターを 0 に設定してパフォーマンスを向上させることができます。

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

  説明

  このパラメーター値が小さく、履歴スナップショットを読み取る際に古い時間を指定すると、SnapshotTooOld エラーが返されます。

rsconf.chainingAllowed

• 適用可能なメジャーバージョン：4.0 以降

• 変更後の再起動要否：不要

• デフォルト値：true

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

• 症状：

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

  • チェーンレプリケーションを有効にすると、セカンダリノードがデータレプリケーションで遅延しやすくなる可能性があります。

• 推奨事項：

  • 4 ノード以下の場合：必要に応じてチェーンレプリケーションを有効または無効にします。

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

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

• 適用可能なメジャーバージョン： 4.2 以降

• 変更後の再起動要否： 不要

• デフォルト値： 104857600 B (100 MB)

• 機能： $push および $addToSet オペレーターが使用できる最大メモリを制限します。

• 症状：$push または $addToSet を含む特定のクエリが失敗し、次のようなエラーメッセージが返されます。

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

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

setParameter.migrateCloneInsertionBatchSize

• 適用可能なメジャーバージョン：4.0 以降

• 変更後の再起動要否：不要

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

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

• 症状：一部のシナリオでは、チャンク移行がシャードのパフォーマンス変動を引き起こす可能性があります。

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

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)

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

• 症状：一部のシナリオでは、チャンク移行後のドキュメントの非同期削除が 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 キャッシュ (WT キャッシュ) に負荷をかける可能性があります。

• 推奨事項：ほとんどの場合、調整は不要です。

  • ビジネスで履歴スナップショットの読み取り (read atClusterTime) 機能を使用しない場合は、このパラメーターを 0 に設定してパフォーマンスを向上させることができます。

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

  説明

  このパラメーター値が小さく、履歴スナップショットを読み取る際に古い時間を指定すると、SnapshotTooOld エラーが返されます。

rsconf.chainingAllowed

• 適用可能なメジャーバージョン：4.0 以降

• 変更後の再起動要否：不要

• デフォルト値：true

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

• 症状：

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

  • チェーンレプリケーションを有効にすると、セカンダリノードがデータレプリケーションで遅延しやすくなる可能性があります。

• 推奨事項：

  • 4 ノード以下の場合：必要に応じてチェーンレプリケーションを有効または無効にします。

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

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

• 適用可能なメジャーバージョン： 4.2 以降

• 変更後の再起動要否： 不要

• デフォルト値： 104857600 B (100 MB)

• 機能： $push および $addToSet オペレーターが使用できる最大メモリを制限します。

• 症状：$push または $addToSet を含む特定のクエリが失敗し、次のようなエラーメッセージが返されます。

  "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 から mongod への接続が確立される速度が制御されます。

• 症状：この値が大きい場合、多くの接続が作成されると 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 接続プールが多くの新しい接続を作成することがあります。これにより、Mongos ノードで CPU スパイクやその他の問題が発生する可能性があります。

• 推奨事項：[10,50] の範囲で適切な値に設定してください。具体的な値は、シャードの数や各シャードのノード数など、シャードクラスターのトポロジーに依存します。Mongos は、これらのアイドル接続をシャードに維持するために、わずかなリソースオーバーヘッドを伴うことに注意してください。

setParameter.cursorTimeoutMillis

• 適用可能なメジャーバージョン：3.0 以降

• 変更後の再起動要否：不要

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

• 機能：アイドル状態のカーソルの有効期限のしきい値 (ミリ秒単位)。カーソルがこのしきい値を超えてアイドル状態になると、MongoDB は自動的にクリーンアップします。

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

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

• 推奨事項：この値を増やさないでください。アイドル状態のカーソルのリソースオーバーヘッドを削減するために、値を 300000 などに減らすことができます。すべてのシナリオで、ビジネス側で長時間アイドル状態のカーソルを持たないようにしてください。