ApsaraDB for MongoDB インスタンスの高い CPU 使用率 (場合によっては 100% に近づく) は、読み書き操作を遅くし、ビジネスオペレーションに支障をきたします。 以下の診断手順を実行して、根本原因を特定し、解決してください。
実行中の操作の確認
mongo シェルを使用してインスタンスに接続します。 接続手順は、インスタンスのアーキテクチャによって異なります。
db.currentOp() を実行して、インスタンスで現在実行中のすべての操作を一覧表示します。
db.currentOp()出力例:
{
"desc" : "conn632530",
"threadId" : "140298196924160",
"connectionId" : 632530,
"client" : "11.xxx.xxx.236:57052",
"active" : true,
"opid" : 1008837885,
"secs_running" : 0,
"microsecs_running" : NumberLong(70),
"op" : "update",
"ns" : "mygame.players",
"query" : {
"uid" : NumberLong(31577677)
},
"numYields" : 0,
"locks" : {
"Global" : "w",
"Database" : "w",
"Collection" : "w"
},
....
}次のフィールドに注目して、問題のある操作を特定します。
フィールド | 説明 | 推奨アクション |
| リクエストを送信したクライアント | これを使用して、リクエストのソースを追跡してください |
| 一意の操作 ID | 必要に応じて |
| 操作の実行時間 (秒単位) | 値が想定外に大きい操作を調査してください |
| 操作の実行時間 (マイクロ秒単位) | 値が想定外に大きい操作を調査してください |
| スキャン対象のネームスペース (コレクション) | スロークエリログと照らし合わせて、ホットなコレクションを特定してください |
| 操作タイプ: | — |
| 操作のロック情報 | FAQ: 同時実行をご参照ください |
db.currentOp() の詳細については、「db.currentOp()」をご参照ください。
CPU 急上昇の一般的な原因は、通常のワークロードと並行して実行される O&M 操作 (フルコレクションスキャンなど) です。 db.currentOp() の出力に、想定外に大きい secs_running 値を持つ操作が表示された場合は、その操作を停止してください。
db.killOp(<opid>)<opid> を db.currentOp() の出力の opid フィールドの値に置き換えます。 詳細については、「db.killOp()」をご参照ください。
スロークエリログの分析
アプリケーションの起動直後に CPU 使用率が上昇し、高いままであるものの、db.currentOp() で明らかな問題のある操作が表示されない場合、原因は時間の経過とともに蓄積されたスロークエリのパターンである可能性が高いです。
ApsaraDB for MongoDB コンソールでスロークエリログを表示します。 詳細については、「スロークエリログの表示」をご参照ください。
スロークエリログエントリの例は次のようになります。
{
"atype": "slowOp",
"param": {
"op": "query",
"ns": "abbott_analysis.uaidScanInfo",
"query": {
"find": "uaidScanInfo",
"filter": {
"dateType": 2,
"companyCode": "GMP"
},
"ntoreturn": -1,
"sort": {
"scanDateTime": -1
}
},
"keysExamined": 0,
"docsExamined": 2181021,
"hasSortStage": true,
"cursorExhausted": true,
"numYield": 17059,
"locks": { ... },
"nreturned": 0,
"responseLength": 20,
"millis": 4878,
"planSummary": "COLLSCAN"
},
"result": "OK"
}スロークエリログで次のパターンを探します。
フルコレクションスキャン (COLLSCAN、docsExamined)
planSummary: COLLSCAN は、クエリがインデックスを使用せずにコレクション全体をスキャンしたことを示します。 docsExamined フィールドは、スキャンされたドキュメントの数を示します。この数値が高いほど、クエリが消費する CPU リソースが多くなります。
これを修正するには、クエリ対象のフィールドにインデックスを作成します。
db.<collection>.createIndex({ <field>: 1 })非効率なインデックス (IXSCAN、keysExamined)
クエリがインデックスを使用する場合、planSummary には IXSCAN が表示されます。 keysExamined フィールドは、スキャンされたインデックスキーの数を示します。 この値が大きいほど、リクエストが使用する CPU リソースが多くなります。
インデックス選択性の例
x フィールドが 2 つの値 (1 または 2) のみを持つのに対し、y ははるかに広い範囲 (1 から 100000) に及ぶコレクションを考えます。 クエリ { x: 1, y: 2 } の場合:
{ x: 1, y: 1 }
{ x: 1, y: 2 }
...
{ x: 1, y: 100000 }
{ x: 2, y: 1 }
...インデックス | 選択性 | 理由 |
| 低い | コレクションの半分が同じ |
| 低い | 先頭フィールド |
| 高い |
|
| 高い | 先頭フィールド |
選択性の高いフィールドを先にインデックスに指定します。 詳細については、「複合インデックス」をご参照ください。
過剰なインデックスは、書き込みおよび更新のパフォーマンスに影響を与えます。 アプリケーションで多数の書き込み操作が行われ、かつインデックスを使用している場合、アプリケーションのパフォーマンスに影響が出る可能性があります。 書き込みパフォーマンスも低下している場合は、未使用のインデックスを特定し、削除してください。
インメモリソート (SORT、hasSortStage)
hasSortStage: true は、ソート順序を満たすインデックスがなかったため、インスタンスがクエリ結果をメモリ内でソートしたことを示します。 大規模な結果セットに対するインメモリソートは、大量の CPU を消費します。
スロークエリログにキーワード SORT が含まれている場合は、ソート句で使用されているフィールドにインデックスを作成します。
db.<collection>.createIndex({ <sort-field>: 1 })その他の高 CPU 操作
インデックスの作成と aggregation パイプライン (トラバーサル、フィルタリング、更新、およびソートを組み合わせるもの) も、高い CPU 使用率の原因となることがあります。同じ診断アプローチとして、低速クエリログで docsExamined、keysExamined、hasSortStage、および planSummary を確認します。
サービス容量の評価
すべてのクエリが適切なインデックスを使用していても CPU 使用率が高いままである場合、インスタンスが容量制限に達している可能性があります。
監視データを確認して、リソース使用状況のパターンを把握します。 詳細については、「監視データの表示」および「ノードモニタリング (旧基本モニタリング)」をご参照ください。
MongoDB データベースをテストして、現在のインスタンスがワークロードに必要なパフォーマンスとサービス容量を提供できるかどうかを判断します。
インスタンスをアップグレードする必要がある場合は、「インスタンスの構成の変更」または「レプリカセットインスタンスのノード数の変更」をご参照ください。
クイックリファレンス
コマンド | 目的 |
| インスタンスで現在実行中のすべての操作を一覧表示します |
| 操作 ID を指定して特定の操作を停止します |
コンソールでスロークエリログを表示 | インスタンスに接続せずにスロークエリを特定します |