すべてのプロダクト
Search
ドキュメントセンター

ApsaraDB for MongoDB:パラメータの最適化に関する推奨事項

最終更新日:Mar 26, 2025

ApsaraDB for MongoDB コンソールで ApsaraDB for MongoDB インスタンスに構成されているパラメータを変更できます。 主要なパラメータに不適切な値が設定されていると、ApsaraDB for MongoDB インスタンスのパフォーマンスが低下したり、アプリケーションにエラーが表示されたりする可能性があります。 このトピックでは、主要なパラメータの最適化に関する推奨事項を提供します。

説明

このトピックではカーネルパラメータのみを扱っており、socketTimeout など、クライアントドライバで構成されるパラメータは除外されています。

レプリカセットインスタンス

operationProfiling.mode

  • サポートされているメジャーバージョン: MongoDB 3.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 必須。

  • デフォルト値: off

  • 機能: クエリプロファイラがプロファイルする操作のレベルを指定します。

  • 問題:

    • このパラメータが all または slowOp に設定されていて、大量のスロークエリログが生成されると、インスタンスのパフォーマンスが低下します。

    • クエリプロファイラの無効化を忘れた場合、データベースに system.profile コレクションが存在するため、一部のユーザーが混乱する可能性があります。

    • また、スロークエリログを生成するために、このパラメータを slowOp に設定する必要があると誤解するユーザーもいるかもしれません。

  • 最適化の提案:

    このパラメーターはデフォルト値のままにすることをお勧めします。クエリプロファイラーを有効にすると、インスタンスのパフォーマンスが低下します。低速クエリログは、一般的に同様の分析情報を提供します。クエリプロファイラーは必要な場合にのみ有効にし、クエリ分析が完了したらすぐに無効にしてください。データベースプロファイラーの詳細については、「プロファイラーのオーバーヘッド」をご参照ください。

operationProfiling.slowOpThresholdMs

  • サポートされているメジャーバージョン: MongoDB 3.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 100

  • 機能: スロークエリを識別するために使用されるしきい値を指定します。

  • 問題:

    • このパラメータに小さすぎる値を設定すると、大量の無関係なスロークエリログと監査ログが生成されます。 これにより、スロークエリの分析に必要な時間が長くなります。

    • このパラメータに大きすぎる値を設定すると、多くのスロークエリがログに記録されません。 これにより、スロークエリの分析に必要な時間も長くなります。

  • 最適化の推奨事項: ビジネス要件に基づいてパラメータ値を増減します。 このパラメータは、ビジネスの主要なクエリの平均継続時間よりも大きい値に設定することをお勧めします。 例:

    • クエリレイテンシに敏感なビジネスにおける毎日のクエリ継続時間が約 30 ミリ秒しかない場合。 一時的なジッターを伴うスロークエリの分析を容易にするために、パラメータ値を 50 に減らします。

    • 分析クエリを含むビジネスにおける毎日のクエリ継続時間が約 300 ~ 400 ミリ秒の範囲にある場合。 毎日のクエリに対して生成されるスロークエリログの数を減らすために、パラメータ値を 500 に増やします。

replication.oplogGlobalIdEnabled

  • サポートされているメジャーバージョン: MongoDB 4.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 必須。

  • デフォルト値: false

  • 機能: Data Transmission Service (DTS) または mongoShake によって実行される双方向同期を高速化するためにグローバル ID (GID) を有効にするかどうかを指定します。 このパラメータは独自に開発されたパラメータです。 GID は、双方向同期で発生する循環同期の問題を修正するために設計されています。

  • 最適化の推奨事項: 双方向同期が必要な場合にのみ、このパラメータを有効にします。 このパラメータは、インスタンスの再起動後にのみ有効になります。 このパラメータは、オフピーク時に変更することをお勧めします。

replication.oplogSizeMB

  • サポートされているメジャーバージョン: MongoDB 3.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: ディスクサイズの 10%。 たとえば、インスタンスのディスクサイズが 500 GB の場合、元のパラメータ値は 51200 で、これは 50 GB に相当します。

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

  • 問題: このパラメータに小さすぎる値を設定すると、セカンダリノードが他のノードに追いつかず、RECOVERING 状態になります。 さらに、ログバックアップはすべての oplog エントリを格納できないため、oplog エントリのデータが失われ、ポイントインタイムリストアが失敗します。

  • 最適化の推奨事項: このパラメータのデフォルト値を維持することをお勧めします。 パラメータ値を減らしないでください。 必要に応じてパラメータ値を増やします。 更新頻度の高い少量のデータを処理し、多数の oplog エントリが生成されるシナリオでは、パラメータ値を増やします。 これにより、oplog は oplog レコードをより長い期間格納できるようになり、oplog エントリのデータ損失を防ぎます。 ベストプラクティスは、oplog コレクションが少なくとも 1 時間分の oplog エントリを保持できるように oplog サイズを設定することです。

説明

システム構成ファイルでこのパラメータを変更しても、このパラメータの変更は有効になりません。 Alibaba Cloud は、replsetResizeOplog コマンドを使用してパラメータ値を調整します。

setParameter.cursorTimeoutMillis

  • サポートされているメジャーバージョン: MongoDB 3.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

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

  • 機能: アイドルカーソルの有効期限のしきい値を指定します。 単位: ミリ秒。 カーソルのアイドル時間がこのしきい値を超えると、ApsaraDB for MongoDB は自動的にカーソルを削除します。

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

    メッセージ: "cursor id xxxxxxx not found"
    エラーコード: CursorNotFound(43)
  • 最適化の推奨事項: パラメータ値を増やさないことをお勧めします。 アイドルカーソルのリソースオーバーヘッドを削減するには、パラメータ値を減らします。 たとえば、パラメータ値を 300000 に減らすことができます。 すべてのシナリオで、長時間アイドル状態のカーソルは使用しないでください。

setParameter.flowControlTargetLagSeconds

  • サポートされているメジャーバージョン: MongoDB 4.2 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 10

  • 機能: flowControl メカニズムをトリガーするためのしきい値を指定します。 このメカニズムは、大部分のデータが指定された秒数以内にコミットされるように設計されています。 詳細については、「Replication Lag and Flow Control」をご参照ください。

  • 問題: 次のようなスロークエリログが生成され、リクエストの応答時間が長くなります。 次のログでは、durationMillis パラメータの値は基本的に flowControl.timeAcquiringMicros パラメータの値と同じであり、これはスローリクエストが主に flowControl メカニズムによって引き起こされていることを示しています。

    {
      "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
      }
    }
    
  • 最適化の推奨事項: flowControl メカニズムの感度を下げるには、パラメータ値を増やします。 パラメータ値を増やした後もリクエストが頻繁にスロットルされる場合は、プライマリインスタンスとセカンダリインスタンス間のデータ同期に関して、インスタンスにパフォーマンスボトルネックが発生しています。 この場合、この問題をさらに分析し、他の方法を採用して前述の問題を修正する必要があります。 たとえば、インスタンスの構成をアップグレードしたり、書き込みコンサーンを majority に設定したりできます。

setParameter.oplogFetcherUsesExhaust

  • サポートされているメジャーバージョン: MongoDB 4.4 以降のバージョン。

  • パラメータ変更後の強制再起動: 必須。

  • デフォルト値: true

  • 機能: ストリームレプリケーションを有効にするかどうかを指定します。 詳細については、「Streaming Replication」をご参照ください。 ストリームレプリケーションを無効にすると、プライマリインスタンスとセカンダリインスタンス間のデータ同期は以前のバージョンと同じデータプル方式に戻ります。 つまり、セカンダリノードは同期ソースにリクエストを送信してバッチの oplog エントリを取得し、応答を待ちます。 これにより、バッチの oplog エントリごとにネットワークを介したラウンドトリップインタラクションが必要になります。

  • 問題: ストリームレプリケーションは、一部のシナリオでパフォーマンスとネットワーク帯域幅のオーバーヘッドを追加で生成する可能性があります。

  • 最適化の推奨事項: このパラメータ値を調整しないことをお勧めします。 ストリームレプリケーションは、高負荷でレイテンシの高いネットワーク環境におけるレプリケーションレイテンシを削減できます。 ただし、書き込みコンサーンが {w:1} であるプライマリノードがクラッシュした場合に書き込まれたデータが失われるリスク、および書き込みコンサーンがプライマリ/セカンダリレプリケーションに依存するレベル ( {w:majority{w:>1} など) に設定されている場合の書き込みレイテンシも発生します。

setParameter.maxTransactionLockRequestTimeoutMillis

  • サポートされているメジャーバージョン: MongoDB 4.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 5

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

  • 問題: ロックの取得のタイムアウトを示す次のエラーメッセージがログまたはクライアントに表示されます。 後のバージョンのドライバは、TransientTransactionError エラーを受け取ると自動的に再試行します。 したがって、エラーはログにのみ表示され、クライアントには認識されない場合があります。

    メッセージ: "Unable to acquire lock '{8442595743001781021: Database, 1525066715360699165}' within a max lock request timeout of '5ms' milliseconds."
    エラーコード: LockTimeout(24)
  • 最適化の推奨事項: クライアントがこのようなエラーを頻繁に受け取る場合は、パラメータ値を増やすことができます。 これにより、同時ロックを即座に取得できなかったことによるトランザクション中止の頻度が減少します。 ただし、デッドロックが発生したトランザクションの中止が遅れます。 パラメータ値を増やした後も前述の問題が解決しない場合は、パラメータ値を再度増やさないことをお勧めします。 代わりに、ビジネスロジックを最適化する必要があります。 たとえば、トランザクション内での同じドキュメントへの同時変更を避け、トランザクション内の操作を確認し、トランザクションに DDL 操作や最適化する必要のあるクエリなど、長時間ロックを占有する操作が含まれているかどうかを確認する必要があります。

setParameter.replWriterThreadCount

  • サポートされているメジャーバージョン: MongoDB 3.2 以降のバージョン。

  • パラメータ変更後の強制再起動: 必須。

  • デフォルト値: 16

  • 機能: プライマリインスタンスとセカンダリインスタンス間の同期時に、レプリケーション操作を並列で実行するために使用されるスレッドの最大数を指定します。 使用されるスレッドの最大数は、CPU コア数の 2 倍に制限されています。

  • 問題: 極端なシナリオでは、プライマリインスタンスとセカンダリインスタンス間のデータ同期の遅延により、セカンダリノードのレイテンシが増加します。

  • 最適化の推奨事項: ほとんどの場合、このパラメータ値を調整しないことをお勧めします。 特殊なケースでは、Alibaba Cloud R&D エンジニアの推奨事項に基づいて調整することをお勧めします。

setParameter.tcmallocAggressiveMemoryDecommit

  • サポートされているメジャーバージョン: MongoDB 4.2 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 0。これは、TCMalloc のアグレッシブリクレー厶戦略が無効になっていることを示します。

  • 機能: TCMalloc のアグレッシブリクレー厶戦略を有効にするかどうかを指定します。 ApsaraDB for MongoDB は、メモリ割り当て子として TCMalloc を使用します。 この戦略を有効にすると、ApsaraDB for MongoDB は隣接する空きメモリブロックをマージし、メモリの一部をオペレーティングシステムに返そうとします。

  • 問題:

    • クエリリクエストのメモリ消費が多すぎるため、mongod のメモリをタイムリーに再利用できず、メモリ不足 (OOM) エラーが返されます。

    • メモリを継続的に使用すると、ヒープメモリの断片化が増加します。 この場合、メモリ使用率は 80% を超え、ゆっくりと着実に増加します。

  • 最適化の推奨事項: ほとんどの場合、このパラメータ値を調整しないことをお勧めします。 メモリ関連の問題が発生した場合は、オフピーク時にこのパラメータ値を調整します。

重要

このパラメータを有効にすると、ワークロードによってはパフォーマンスが低下する可能性があります。 このパラメータは、オフピーク時にのみ有効にし、パラメータ調整後も一定期間ビジネスを観察し続けることをお勧めします。 ビジネスに影響がある場合は、タイムリーにパラメータ調整をロールバックしてください。

setParameter.transactionLifetimeLimitSeconds

  • サポートされているメジャーバージョン: MongoDB 4.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 60

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

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

    メッセージ: "Aborting transaction with txnNumber xxx on session with lsid xxxxxxxxxx because it has been running for longer than 'transactionLifetimeLimitSeconds'"
  • 最適化の推奨事項: パラメータ値を減らします。 たとえば、パラメータ値を 30 に減らすことができます。 パラメータ値を増やさないことをお勧めします。 コミットされていない長いトランザクションは、WiredTiger キャッシュに過剰なワークロードをかける可能性があります。 キャッシュが過負荷になると、データベースの停止、応答レイテンシの大幅な増加、CPU 使用率の高さなど、多くの問題が発生します。 これにより、ビジネスに損害が発生します。 すべてのシナリオで長いトランザクションは使用しないでください。 タイムアウトの問題を修正するには、トランザクションを小さな部分に分割して、一定時間内にトランザクションを完了できるようにします。 クエリ文が最適化され、適切なインデックスカバレッジが提供されていることを確認して、トランザクションでのデータアクセスを迅速に行えるようにします。

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

storage.oplogMinRetentionHours

  • サポートされているメジャーバージョン: MongoDB 4.4 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 0。これは、このパラメータが有効ではなく、oplog サイズが replication.oplogSizeMB パラメータによって指定されていることを示します。

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

  • 問題:

    • このパラメータに大きすぎる値を設定すると、oplog コレクションが大量のディスク容量を占有します。

    • 一部のユーザーは、このパラメータの指定を忘れてしまい、ディスクサイズの変動に混乱する可能性があります。

  • 最適化の推奨事項: ワークロードが安定している場合は、このパラメータのデフォルト値を維持することをお勧めします。 書き込み操作に大きな変更がある場合は、このパラメータを 1.0 より大きい浮動小数点数に設定することをお勧めします。 このパラメータを構成する際には、インスタンスがディスク容量の枯渇によってロックされるシナリオを回避するために、占有できるディスク容量を評価します。

storage.wiredTiger.collectionConfig.blockCompressor

  • サポートされているメジャーバージョン: MongoDB 3.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 必須。

  • デフォルト値: snappy

  • 機能: コレクションデータのデフォルトのストレージ圧縮アルゴリズムを指定します。 デフォルトのストレージ圧縮アルゴリズムを変更すると、新しいコレクションのみが指定された新しいアルゴリズムを使用します。 既存のコレクションは影響を受けません。 このパラメータは、none、snappyzlib、または zstd に設定できます。 zstd の値は、MongoDB 4.2 以降のバージョンを実行しているインスタンスでのみ使用できます。

  • 最適化の推奨事項: ビジネス要件に基づいてパラメータ値を変更します。 圧縮アルゴリズムごとにパフォーマンス特性が異なります。 いくつかの圧縮アルゴリズムは高い圧縮率を提供しますが、圧縮と展開のために高い CPU オーバーヘッドをもたらします。 対応するテスト結果を参照して、さまざまな圧縮アルゴリズムの実際のパフォーマンスを理解してください。 インスタンスが主にコールドデータを格納する場合は、パラメータ値を zstd に変更して、より高い圧縮率を実現できます。

    説明

    コレクションごとに異なる圧縮アルゴリズムを使用する場合は、関連オプションを提供する明示的な createCollection コマンドを使用します。 詳細については、「Specify Storage Engine Options」をご参照ください。

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

  • サポートされているメジャーバージョン: MongoDB 4.4 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 300。単位: 秒。 デフォルト値は 5 分です。

  • 機能: WiredTiger でスナップショットが保持される期間を指定します。 値 0 は、期間が閉じていることを示します。 このパラメータは、atClusterTime パラメータで指定された時点でのデータ読み取りをサポートします。 詳細については、「Read Concern and atClusterTime」をご参照ください。

  • 問題: このパラメータは、特にドキュメントが頻繁に更新される場合、WiredTiger キャッシュに負荷をかけます。

  • 最適化の推奨事項: ほとんどの場合、このパラメータ値を調整する必要はありません。

    • read atClusterTime 機能を使用しない場合は、パフォーマンスを向上させるために、このパラメータを 0 に設定できます。

    • 5 分以上前に生成されたスナップショットを読み取る場合は、このパラメータをより大きい値に設定できます。 ただし、パラメータ値の増加によって引き起こされる追加のメモリ消費量とパフォーマンスオーバーヘッドにも注意を払う必要があります。

    説明

    このパラメータを小さい値に設定し、スナップショットの読み取りに以前の時点を指定すると、SnapshotTooOld エラーが発生します。

    rsconf.chainingAllowed

    • サポートされているメジャーバージョン: MongoDB 4.0 以降のバージョン。

    • パラメータ変更後の強制再起動: 不要。

    • デフォルト値: true

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

    • 問題:

      • レプリカセットインスタンスのチェーンレプリケーションが無効になっている場合、インスタンス内のプライマリノードは、CPU 使用率やネットワークトラフィックの増加など、より高い負荷を負担する可能性があります。

      • レプリカセットインスタンスのチェーンレプリケーションが有効になっている場合、インスタンスのセカンダリノードでデータラグが発生する可能性があります。

  • 最適化の推奨事項:

    • レプリカセットインスタンスに最大 4 つのノードが含まれている場合、ビジネス要件に基づいてインスタンスのチェーンレプリケーションを有効または無効にできます。

    • レプリカセットインスタンスに 5 つ以上のノードが含まれており、インスタンスの writeConcern が {w:majority} に設定されている場合、プライマリノードの負荷とインスタンスのパフォーマンスのバランスをとる必要があります。 チェーンレプリケーションを無効にすると、インスタンスの書き込みパフォーマンスは向上します。 ただし、プライマリノードの負荷が大幅に増加します。

シャードクラスターインスタンス (シャードでのみ使用可能なパラメータ)

setParameter.migrateCloneInsertionBatchSize

  • サポートされているメジャーバージョン: MongoDB 4.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 0。これは、バッチに最大 16 MB のドキュメントを含めることができることを示します。

  • 機能: チャンク移行プロセスのクローニングステージで 1 つのバッチに挿入するドキュメントの最大数を指定します。

  • 問題: 一部のシナリオでは、チャンク移行プロセス中にシャードでパフォーマンスの変動が発生します。

  • 最適化の推奨事項: ほとんどの場合、このパラメータ値を調整する必要はありません。 チャンク移行による負荷分散中にシャードクラスターインスタンスでパフォーマンスの変動が発生する場合は、このパラメータ値を固定バッチサイズに調整します。

setParameter.rangeDeleterBatchDelayMS

  • サポートされているメジャーバージョン: MongoDB 4.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 20

  • 機能: チャンク移行プロセスのクリーンアップステージで、次のバッチの削除の前に待機する間隔を指定します。 単位: ミリ秒。 このパラメータは、孤立ドキュメントをクリーンアップするために使用される cleanupOrphaned コマンドに影響します。

  • 問題:

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

    • このパラメータに大きすぎる値を設定すると、ドキュメントがタイムリーに削除されないため、孤立する可能性があります。 さらに、多数のドキュメントを削除する操作がタイムアウトしたため、次のエラーメッセージが返される場合があります:

      メッセージ: "OperationFailed: Data transfer error: ExceededTimeLimit: Failed to delete orphaned <db>.<collection> range [xxxxxx,xxxxx] :: caused by :: operation exceeded time limit"
  • 最適化の推奨事項: ほとんどの場合、このパラメータ値を調整する必要はありません。 負荷分散中にドキュメントの非同期削除によってシャードクラスターインスタンスの CPU 使用率が急上昇する場合は、パラメータ値を増やすことができます。 たとえば、パラメータ値を 200 に増やします。

setParameter.rangeDeleterBatchSize

  • サポートされているメジャーバージョン: MongoDB 4.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 0。これは、システムが適切な値を使用することを示します。 ほとんどの場合、値は 128 です。

  • 機能: チャンク移行プロセスのクリーンアップステージで、非同期削除の 1 つのバッチに含まれるドキュメントの最大数を指定します。

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

  • 最適化の推奨事項: ほとんどの場合、このパラメータ値を調整する必要はありません。 負荷分散中にドキュメントの非同期削除によってシャードクラスターインスタンスの CPU 使用率が急上昇する場合は、このパラメータ値を固定バッチサイズに調整します。

説明

このパラメータと setParameter.rangeDeleterBatchDelayMS パラメータはどちらも、チャンク移行後の非同期ドキュメント削除プロセスに影響します。 2 つのパラメータの値を個別に調整できます。 あるいは、2 つの値を組み合わせて、または段階的に調整することもできます。

setParameter.chunkMigrationConcurrency

  • サポートされているメジャーバージョン: MongoDB 5.0 および 7.0。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 1

  • 機能: チャンクの移行に使用される同時スレッド数を指定します。

  • 問題: シャードの追加や削除など、一部のシナリオでは、バランサーによってチャンクがゆっくりと移行され、高速化が必要になる場合があります。

  • 最適化の推奨事項: ほとんどの場合、このパラメータ値を調整する必要はありません。 バランスプロセスを高速化するには、パラメータ値を増やすことができます。 調整後、インスタンスの負荷とビジネスへの影響に注意を払う必要があります。 問題が発生した場合は、パラメータ値をタイムリーにロールバックする必要があります。

setParameter.receiveChunkWaitForRangeDeleterTimeoutMS

  • サポートされているメジャーバージョン: MongoDB 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

  • サポートされているメジャーバージョン: MongoDB 4.4 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 300。単位: 秒。 デフォルト値は 5 分です。

  • 機能: WiredTiger でスナップショットが保持される期間を指定します。 値 0 は、期間が閉じていることを示します。 このパラメータは、atClusterTime パラメータで指定された時点でのデータ読み取りをサポートします。 詳細については、「Read Concern and atClusterTime」をご参照ください。

  • 問題: このパラメータは、特にドキュメントが頻繁に更新される場合、WiredTiger キャッシュに負荷をかけます。

  • 最適化の推奨事項: ほとんどの場合、このパラメータ値を調整する必要はありません。

    • read atClusterTime 機能を使用しない場合は、パフォーマンスを向上させるために、このパラメータを 0 に設定できます。

    • 5 分以上前に生成されたスナップショットを読み取る場合は、このパラメータをより大きい値に設定できます。 ただし、パラメータ値の増加によって引き起こされる追加のメモリ消費量とパフォーマンスオーバーヘッドにも注意を払う必要があります。

    説明

    このパラメータを小さい値に設定し、スナップショットの読み取りに以前の時点を指定すると、SnapshotTooOld エラーが発生します。

    rsconf.chainingAllowed

    • サポートされているメジャーバージョン: MongoDB 4.0 以降のバージョン。

    • パラメータ変更後の強制再起動: 不要。

    • デフォルト値: true

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

    • 問題:

      • レプリカセットインスタンスのチェーンレプリケーションが無効になっている場合、インスタンス内のプライマリノードは、CPU 使用率やネットワークトラフィックの増加など、より高い負荷を負担する可能性があります。

      • レプリカセットインスタンスのチェーンレプリケーションが有効になっている場合、インスタンスのセカンダリノードでデータラグが発生する可能性があります。

  • 最適化の推奨事項:

    • レプリカセットインスタンスに最大 4 つのノードが含まれている場合、ビジネス要件に基づいてインスタンスのチェーンレプリケーションを有効または無効にできます。

    • レプリカセットインスタンスに 5 つ以上のノードが含まれており、インスタンスの writeConcern が{w:majority} に設定されている場合、プライマリノードの負荷とインスタンスのパフォーマンスのバランスをとる必要があります。 チェーンレプリケーションを無効にすると、インスタンスの書き込みパフォーマンスは向上します。 ただし、プライマリノードの負荷が大幅に増加します。

rsconf.chainingAllowed

  • サポートされているメジャーバージョン: MongoDB 4.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: true

  • シャードクラスターインスタンスのシャードでチェーンレプリケーションを許可するかどうかを指定します。

  • 問題:

    • シャードクラスターインスタンスのチェーンレプリケーションが無効になっている場合、インスタンス内のプライマリノードは、CPU 使用率やネットワークトラフィックの増加など、より高い負荷を負担する可能性があります。

    • シャードクラスターインスタンスのチェーンレプリケーションが有効になっている場合、インスタンスのセカンダリノードでデータラグが発生する可能性があります。

  • 最適化の推奨事項:

    • シャードクラスターインスタンスに最大 4 つのノードが含まれている場合、ビジネス要件に基づいてインスタンスのチェーンレプリケーションを有効または無効にできます。

    • シャードクラスターインスタンスに 5 つ以上のノードが含まれており、インスタンスの writeConcern が{w:majority} に設定されている場合、プライマリノードの負荷とインスタンスのパフォーマンスのバランスをとる必要があります。 チェーンレプリケーションを無効にすると、インスタンスの書き込みパフォーマンスは向上します。 ただし、プライマリノードの負荷が大幅に増加します。

シャードクラスターインスタンス (mongos でのみ使用可能なパラメータ)

operationProfiling.slowOpThresholdMs

  • サポートされているメジャーバージョン: MongoDB 3.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

  • デフォルト値: 100

  • 機能: スロークエリを識別するために使用されるしきい値を指定します。

  • 問題:

    • このパラメータに小さすぎる値を設定すると、大量の無関係なスロークエリログと監査ログが生成されます。 これにより、スロークエリの分析に必要な時間が長くなります。

    • このパラメータに大きすぎる値を設定すると、多くのスロークエリがログに記録されません。 これにより、スロークエリの分析に必要な時間も長くなります。

  • 最適化の推奨事項: ビジネス要件に基づいてパラメータ値を増減します。 このパラメータは、ビジネスの主要なクエリの平均継続時間よりも大きい値に設定することをお勧めします。 例:

    • クエリレイテンシに敏感なビジネスにおける毎日のクエリ継続時間が約 30 ミリ秒しかない場合。 一時的なジッターを伴うスロークエリの分析を容易にするために、パラメータ値を 50 に減らします。

    • 分析クエリを含むビジネスにおける毎日のクエリ継続時間が約 300 ~ 400 ミリ秒の範囲にある場合。 毎日のクエリに対して生成されるスロークエリログの数を減らすために、パラメータ値を 500 に増やします。

setParameter.ShardingTaskExecutorPoolMaxConnecting

  • サポートされているメジャーバージョン: MongoDB 3.6 以降のバージョン。

  • パラメータ変更後の強制再起動:

    • MongoDB 3.6 および MongoDB 4.0 の場合: 必須。

    • MongoDB 4.2 以降のバージョンの場合: 不要。

  • デフォルト値: 2

  • 機能: 接続の初期化中に、シャードクラスターインスタンスの mongos ノードの TaskExecutor 接続プールで確立できる接続の最大数を指定します。 このパラメータは、mongos と mongod 間の接続確立の速度を指定します。

  • 問題: このパラメータに大きい値を設定すると、多数の接続が確立されたときに mongos ノードの CPU 使用率が急上昇する可能性があります。

  • 最適化の推奨事項: このパラメータ値を調整しないことをお勧めします。

setParameter.ShardingTaskExecutorPoolMaxSize

  • サポートされているメジャーバージョン: MongoDB 3.6 以降のバージョン。

  • パラメータ変更後の強制再起動:

    • MongoDB 3.6 および MongoDB 4.0 の場合: 必須。

    • MongoDB 4.2 以降のバージョンの場合: 不要。

  • デフォルト値: 2^64-1。これは、INT64 データ型の最大値を示します。

  • 機能: シャードクラスターインスタンスの mongos ノードの各 TaskExecutor 接続プールにおける接続の最大数を指定します。

  • 最適化の推奨事項: このパラメータ値を調整する必要はありません。 mongos とシャード間で確立できる接続の最大数を制限するようにパラメータを構成します。 パラメータに小さい値を設定しないことをお勧めします。 このパラメータに小さい値を設定すると、すべての接続が使い果たされたときに mongos のリクエストがブロックされます。

setParameter.ShardingTaskExecutorPoolMinSize

  • サポートされているメジャーバージョン: MongoDB 3.6 以降のバージョン。

  • パラメータ変更後の強制再起動:

    • MongoDB 3.6 および MongoDB 4.0 の場合: 必須。

    • MongoDB 4.2 以降のバージョンの場合: 不要。

  • デフォルト値: 1

  • 機能: シャードクラスターインスタンスの mongos ノードの各 TaskExecutor 接続プールにおける接続の最小数を指定します。

  • 問題: 一部のシナリオでは、mongos でのバーストリクエストにより、TaskExecutor 接続プールで多数の追加接続を確立する必要があり、mongos で CPU 使用率の急上昇などの問題が発生します。

  • 最適化の推奨事項: シャードの数と各シャードのノード数に応じて、パラメータを 10 ~ 50 の範囲の値に設定することをお勧めします。 mongos がシャードへのアイドル接続を維持する場合、リソースオーバーヘッドは低くなります。

setParameter.cursorTimeoutMillis

  • サポートされているメジャーバージョン: MongoDB 3.0 以降のバージョン。

  • パラメータ変更後の強制再起動: 不要。

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

  • 機能: アイドルカーソルの有効期限のしきい値を指定します。 単位: ミリ秒。 カーソルのアイドル時間がこのしきい値を超えると、ApsaraDB for MongoDB は自動的にカーソルを削除します。

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

    メッセージ: "cursor id xxxxxxx not found"
    エラーコード: CursorNotFound(43)
  • 最適化の推奨事項: パラメータ値を増やさないことをお勧めします。 アイドルカーソルのリソースオーバーヘッドを削減するには、パラメータ値を減らします。 たとえば、パラメータ値を 300000 に減らすことができます。 すべてのシナリオで、長時間アイドル状態のカーソルは使用しないでください。