CPU使用率は、ApsaraDB for MongoDBインスタンスを監視するための重要な指標です。 インスタンスのCPU使用率が高すぎると、インスタンスの応答が遅くなり、サービスの提供に失敗することさえあります。 このトピックでは、ApsaraDB for MongoDBインスタンスのCPU使用率を表示し、CPU使用率が高い問題のトラブルシューティングを行う方法について説明します。
アクセス方式
モニタリングチャートでのCPU使用率の表示: ApsaraDB for MongoDBコンソールのApsaraDB for MongoDBインスタンスの [モニタリングデータ] ページで、インスタンスのCPU使用率をモニタリングチャートで表示できます。 モニタリング間隔と手順の詳細については、「基本的なモニタリング」をご参照ください。
ApsaraDB for MongoDBは、インスタンスアーキテクチャにさまざまなノードの組み合わせを提供します。 ノードを選択して、そのCPU使用率を表示できます。
レプリカセットインスタンスレプリカセットインスタンスは、プライマリノード、1つ以上のセカンダリノード、隠しノード、および1つ以上のオプションの読み取り専用ノードで構成されます。
シャードクラスタインスタンスシャードクラスタインスタンスは、1つ以上のシャードコンポーネント、ConfigServerコンポーネント、および1つ以上のmongosコンポーネントで構成されます。 シャードコンポーネントのCPU消費量は、レプリカセットインスタンスのCPU消費量と同じです。 ConfigServerコンポーネントは、構成メタデータのみを格納するため、ほとんどのCPUボトルネックの影響を受けません。 mongosコンポーネントのCPU使用率は、集計結果セットと同時要求の数によって異なります。
CPU使用率はインスタンスの仕様にも依存します。 たとえば、インスタンスに8つのCPUコアと16 GBのメモリが搭載され、CPU使用率が100% の場合、8つのCPUコアが使い果たされます。 この例では、CPU使用率は800% ではなく100% として表示されます。
一般的な原因
過剰なドキュメントのスキャン
ApsaraDB for MongoDBはマルチスレッドをサポートしています。 1つのクエリで多数のドキュメントをスキャンする必要がある場合、クエリを実行するスレッドはCPUリソースを長時間占有します。 保留中のリクエストまたは多数のドキュメントをスキャンする必要があるクエリの同時実行性が高い場合、クエリが実行されるインスタンスでCPU使用率が高くなります。 インスタンスのCPU使用率は、インスタンス内のスキャンされたドキュメントの総数に正の関係があります。 多くの場合、大量のドキュメントをスキャンする必要があるクエリは、次のシナリオで一般的です。
完全収集スキャン
スロークエリログまたはsystem.profileという名前のコレクションで
COLLSCANキーワードが見つかった場合、クエリで完全なコレクションスキャンが実行されます。 データベースプロファイリングを有効にすると、システムは自動的にコレクションを作成します。 低速クエリログを表示し、データベースプロファイリングを構成する方法の詳細については、「低速クエリログ」をご参照ください。不当なインデックスデザインと使用法
クエリで
docsExaminedキーワードの値が1,000より大きく、クエリが頻繁に実行される場合は、クエリに集中する必要があります。 キーワードは、クエリでスキャンされたドキュメントの数を示します。 完全なコレクションスキャンに加えて、次のシナリオでは、docsExaminedキーワードの値が大きくなります。複数のフィルタ条件が使用されるとき、複合インデックスが使用されないか、またはプレフィックスマッチング原理が満たされない。
クエリは複雑であるか、または多数の集計操作を伴うため、最適化できない無効な解析ポリシーまたはインデックスが発生する可能性があります。
データフィールドのデータ選択性は、選択周波数とアンバランスである。
過剰な同時実行
多数のサービス要求が送信され、同時実行性が過度に高い場合、CPU使用率は高くなります。 この高いCPU使用率の問題を解決するには、クエリの問題が発生しないことを確認した場合にCPUコアを追加します。
その他の原因
多数の短命接続が確立される。 MongoDB 3.X以降のバージョンでは、ハッシュ計算などのCPU集約型の操作を必要とするデフォルトのID認証メカニズムがSCRAM-SHA1されます。 短期間の接続の同時実行性が高い場合、ハッシュ計算は複数のCPUリソースを消費し、さらにはCPUリソースを使い果たします。 この場合、運用ログには多数のsaslStartエラーメッセージが含まれています。 同時実行性の高いシナリオでPHPの短期間の接続を最適化するために、ApsaraDB for MongoDBは、カーネル層で組み込みのランダム関数を書き直す方法を最適化します。 これにより、インスタンスのCPU使用率を削減できます。
生存時間 (TTL) インデックスは、プライマリノードよりもセカンダリノードのCPU使用率を高くします。 この場合、ノードの高いCPU使用率を無視することを推奨します。
MongoDB 3.2以降はマルチスレッドレプリケーションをサポートしています。 oplogsのロールバック同時実行は、replWriterThreadCountパラメーターによって決定されます。 このパラメーターのデフォルト値は16です。 セカンダリノードは、ビジネスクリティカルな書き込みワークロードを処理しません。 しかしながら、セカンダリノードのCPU利用率は、プライマリノードのCPU利用率よりも高い可能性がある。 たとえば、TTLを使用してデータの有効期限が切れたときにコレクション内のデータを削除すると、システムは時間列のインデックスに基づいて一度に大量のデータを効率的に削除できます。 システムは、削除操作を複数の削除操作に変換し、操作をセカンダリノードに送信します。 セカンダリノードでは、oplogのロールバックは効率が低くなります。 oplogのマルチスレッド化されたロールバックは、ノードのCPU利用率を増加させ得る。
トラブルシューティング
アクティブセッションの表示と終了
実行中状態のインスタンスのサージングセッションは、CPUリソースの100% を消費する可能性があります。 この場合、高いCPU使用率は、ビジネストラフィックの変化によって引き起こされる可能性があります。 その他の考えられる原因には、大量のドキュメントを含むスキャン、データの並べ替えと集約、ビジネストラフィックの急増などがあります。 次のいずれかの方法を使用して、高いCPU使用率をトラブルシューティングできます。
ApsaraDB for MongoDBコンソールで、管理するインスタンスのIDをクリックします。 左側のナビゲーションウィンドウで、 を選択します。 表示されるページで、現在のアクティブなセッションを表示し、予想される実行期間内に完了していないクエリ操作を分析してから、異常なアクティブなセッションを終了します。 追加の方法を使用して、高いCPU使用率の問題を解決することもできます。
アクティブなセッションの詳細を表示および分析するには、MongoDBが提供するdb.currentOp() コマンドを実行します。 必要に応じて、db.killOp() コマンドを実行して、予想される実行期間内に完了しなかった低速クエリをアクティブに終了します。 詳細については、「db.currentOp() 」および「db.killOp() 」をご参照ください。
記録と表示ログ
CPU使用率が異常に増加した場合、監査ログまたはスロークエリログを使用して異常なリクエストを分析できます。 COLLSCANやdocsExaminedなどのキーワードを表示して、スキャンしたドキュメントの数が多すぎるかどうかを確認します。
監査ログ
ApsaraDB for MongoDBコンソールに移動し、 を選択して監査ログ機能を有効にします。 機能を有効化および使用する方法の詳細については、「監査ログ機能の有効化」をご参照ください。
スロークエリログ
重要スロークエリログの保持期間は7日です。
2021年6月6日以降にインスタンスを購入し、インスタンスの低速クエリログを表示する場合は、監査ログ機能を有効にし、監査するadminおよびslow操作タイプを選択する必要があります。 監査ログ機能を有効にした後に生成される低速クエリログのみを表示できます。
ApsaraDB for MongoDBコンソールに移動し、 を選択します。 パラメーターリストタブで、operationProfiling.mo deおよびoperationProfiling.slowOpThresholdMsパラメーターを設定できます。 operationProfiling.mo deパラメーターは、プロファイリングレベルを指定します。 operationProfiling.slowOpThresholdMsパラメーターは、低速クエリのしきい値を指定します。
ApsaraDB for MongoDBでは、次のプロファイリングレベルを使用できます。
プロファイリングは無効になり、データは収集されません。
すべてのリクエストに対してプロファイリングが有効になります。 すべてのリクエストの実行データがsystem.profileコレクションに記録されます。
低速クエリに対してプロファイリングが有効になります。 指定されたしきい値よりも時間がかかるクエリは、system.profileコレクションに記録されます。
プロファイリングパラメーターの詳細については、「Database Profiler」をご参照ください。
低速クエリログを表示するには、 を選択します。
最適化ポリシー
インデックスの最適化
インデックスの最適化は、1つのクエリでスキャンするドキュメントの数を減らすための最良のソリューションです。 基盤となるアーキテクチャでは、ApsaraDB for MongoDBはMySQLと同様のインデックスデザインを使用し、MySQLよりも豊富なカテゴリと機能を提供します。 したがって、MySQLに適用されるほとんどのインデックス最適化ポリシーは、ApsaraDB for MongoDBにも適用されます。
インデックスの作成方法と使用方法の詳細については、「ApsaraDB For MongoDBでインデックスを作成するためのベストプラクティス」または次の公式ドキュメントをご参照ください。
複合インデックスの詳細については、「複合インデックス」をご参照ください。
インデックスを使用してクエリ結果をソートする方法の詳細については、「インデックスを使用してクエリ結果をソートする」をご参照ください。
ヒントの詳細については、「Cursorメソッド」および「cursor.hint() 」をご参照ください。
データフィールドのデータ選択性と選択頻度のバランスを取る方法の詳細については、「選択性を確保するクエリの作成」をご参照ください。
CPUコアの追加
クエリの問題が発生しないことを確認した場合、高いCPU使用率は、サービス要求の数が多く、同時実行性が高いことが原因です。 CPUコアを追加して、CPU使用率の高い問題を解決できます。 ほとんどの場合、次のいずれかの方法を使用してCPUコアを追加できます。
1つのインスタンスをスケールアップして、読み取りおよび書き込みワークロードを増やします。
レプリカセットインスタンスの読み書き分離を設定するか、インスタンスに読み取り専用ノードを追加します。
線形スケールアウトのために、問題のあるインスタンスをシャードクラスタインスタンスにアップグレードします。
mongosノードのCPUリソースが使い果たされた場合、mongosノードを追加し、ノードの負荷分散を設定する必要があります。 詳細については、「ApsaraDB For MongoDBシャードクラスターインスタンスの概要」トピックのBalancerセクションをご参照ください。
ApsaraDB For MongoDBインスタンスの設定を変更する方法の詳細については、「スタンドアロンインスタンスの設定の変更」、「レプリカセットインスタンスの設定の変更」、および「シャードクラスターインスタンスの設定の変更」をご参照ください。
収集量と実行頻度の範囲
完全収集スキャンを最適化するためにインデックスを追加することを推奨します。 この方法がうまく機能しない場合は、ビジネス側でコレクションのデータ量と完全コレクションスキャンの実行頻度をスコープすることをお勧めします。
短命の接続数を最小限に抑える
永続接続の使用を推奨します。