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