MongoDBのCPU使用率が高い、破るためにどのように（ターン）

ユーザーは、多くの場合、ご相談：MongoDBのCPU使用率は、両方のフルスプリント高いですが、私はどのようにすればよいですか？

この問題が発生し、99.9999％の可能性が高いMongoDBのCPU使用率の問題をトラブルシューティングする方法の応用の観点から、本稿では「不合理に起因するユーザの」あります。

ステップ1：要求データベースの分析が行われています

ユーザーはMongoのシェルを接続し、db.currentOp（）コマンドを実行することができ、データベース操作が現在実行されて見ることができ、次のコマンドの出力、ロゴで実行される動作の一例です。いくつかのフィールドにフォーカス：

クライアント：クライアントによって開始された要求？
OPID：OPID操作、必要に応じて、db.killOp（OPID）を直接殺傷することによって操作することができます。
secs_running / microsecs_running：この値は焦点、時間は、この値が特に大きい場合、あなたは要求が妥当であるかどうかを確認するために注意を払わなければならない、要求に代わって実行されています。
クエリ/ NS：これは、それがどのコレクションにやっているかを見ることができます。
*ロック：ロックといくつかの関連パラメータで、文書ではなく、詳細な説明することができ、あなたが知っておくべきネットワークを教えてください。

{ 
        "DESC"： "conn632530"、
        "スレッドID"： "140298196924160"、
        "connectionId"：632530、
        "クライアント"： "11.192.159.236:57052"、
        "アクティブ"：真、
        "OPID"：1008837885、
        "secs_running" ：0、
        "microsecs_running"：NumberLong（70）、
        "OP"： "更新"、
        "NS"： "mygame.players"、
        "クエリ"：{ 
            "UID"：NumberLong（31577677）
        }、
        "numYields"：0 、
        "ロック"：{ 
            "グローバル」： "W"、 
            "データベース"： "W"、
            "コレクション"： "" W 
        }、
        ... 
}、

ここでは最後に、db.currentOpによって実行される操作を表示する）（、それについて明確にすることを目的は何かありますか？

私たちは、操作が実行されて欲しいと言っているわけではないリストされ、その後、killOpによって一つ一つを殺し、このステップの目的は、実行されている「予期せぬ」時間のかかる要求があるかどうかを見ることです。

例えば、あなたのビジネスは通常、テーブル全体をスキャンするために必要な操作の数を実行するためにデータベースに接続された高CPU使用率、運用、保守管理要員はありませんが、突然あなたのビジネスに非常に遅い応答が得られ、高いCPU使用率を急上昇し、その後、私たちは次のことに集中しなければなりませんこれらの実行時間が非常に長い操作です。

犯人が見つかると、対応する要求OPIDはdb.killOp（OPID）が対応する要求を取り除く実行します。

あなたは、オンラインで使用する場合は、CPU使用率が高く、より詳細な分析ステップ2に入力することができ、また、何も珍しい要求を見つけられませんでしたdb.currentOp結果で続けてきました。

ステップ2：分析データベース遅い要求

サポート機能をプロファイリングMongoDBは、中に設定された同じDBのsystem.profileに要求されたレコードの実装は、プロファイリングは、3つのモードがあります。

閉じるプロファイリング;
すべての要求のためのオープンプロファイリングは、すべての要求がセットsystem.profileするために記録され、実行します。
遅い要求に対してプロファイリング、要求はsystem.profile記録設定特定の閾値を超えています。

プロファイリング機能をオフにし、本番環境をオンすることをお勧めしますデフォルトでは、要求、MongoDBは、スローリクエストしきい値は直接デフォルト値の100ミリ秒を使用し、そのような不確実性など、ニーズに応じてカスタマイズすることができます。

operationProfiling：
  モード：slowOp 
  slowOpThresholdMs：100

上記構成レコードに基づいて、要求がMongoDBのsystem.profile DBの対応するセットに100ミリ秒を超えることになる、デフォルトのsystem.profileキャップを回収1メガバイトは、スペースのほとんどを占めています。

{natrual $：-1}、最新の3つの遅い要求を参照してください。逆挿入による序数の代表

db.system.profile.find（）ソート（{natrual $：-1}）。限界（3）

（MongoDBのクラウドデータベースが遅い要求のデフォルトのプロファイルで有効になっている）の下プロファイリングオープン遅い要求の場合には、我々は共通含めて可能な最適化ポイントを識別するために要求された分析を遅くする内容でした。

CPUのキラー1：フルテーブルスキャン

フル・コレクション（表）は、クエリ（または更新、削除）要求がフルテーブルスキャンを必要とするとき、COLLSCANを、スキャンしている非常に時間がCPUリソースを消費するので、あなたは、ファイルまたはsystem.profileの見つけセットCOLLSCANキーワードをログインしたときに、あなたがする必要があります確認し、そのような要求はより頻繁に、それはクエリのインデックスフィールドを最適化することが最善である場合、注意、これらのクエリは、あなたのCPUリソースを食べている可能性があります。

クエリがドキュメントの数をスキャンし、あなたはdocsExaminedのsystem.profile、値が大きいほど、より大きな要求CPUのオーバーヘッドの値を見ることができます。

>キーワード：COLLSCAN、docsExamined

CPUのキラー2：非合理的なインデックス

時には、でもインデックスを行くためのクエリ要求ならば、実装は通常、合理的なの確立合理的ではないので（またはそれ自体が試合の多くの結果である、そうでもインデックスを取って、要求が最適化の多くを費やすことはありません）、非常に遅いです。

データセットを想定し、以下に示すように、値フィールドのy値が非常に豊富であるが、（1,2のみを仮定して）小さなフィールドxは。

{X：1、1} 
、{X：1、2} 
、{X：1、3} 
... 
{X：1、および：100000} 
{X：2、及び1 } 
{X：2、2} 
、{x：2、及び3} 
... 
{X：1、および：100000}

このようなクエリ{：1：Y 2、X}をサーブします

同じx値ので無効、あまりに; db.createIndex（{1、X}）
db.createIndex：無効、同じx値すぎるため、（{X :. 1、Y} 1）
DB。 CREATEINDEX（{Y：1}）ため、同じyの値以下の効果が良好であり、
db.createIndex（{Y :. 1、X：} 1）優れた結果、以下同じY値からです。

そして：{1、Y}と{Y：1、X：1}差、参照インデックスのMongoDB原理及びその複合インデックス公式文書を自己が理解。

クエリのインデックスを撮影、インデックスをスキャンしますどのように多くの、あなたが大きい、keysExaminedフィールドの値、大きいCPUのオーバーヘッドをsystem.profileを表示することができます。

>キーワード：IXSCAN、keysExamined

CPUのキラー3：大量のデータをソートします

クエリ要求がソート含まれている場合は、ソートは、MongoDBのメモリリー結果のランキング、そして非常にCPUリソースを消費している、それ自体でこのアクションを並べ替え満たすために、インデックスを通じて行われることができない場合は、最適化の方法は、まだインデックスが作成され、多くの場合、ソートする必要がありますフィールドのインデックス。

いつsystem.profileコレクションやログファイルには、SORTキーワード、あなたがインデックスによってソート最適化することを検討することができました。要求がソート相が含まれている場合、hasSortStageフィールドのsystem.profileはtrueになります。

>キーワード：SORT、hasSortStage

インデックスの組み合わせは、全表スキャンを必要とするだけでなく、vaggeregationトラバーサル、クエリ、更新、並べ替えやその他のアクション、また、非常にCPUリソースを消費することができ、そのようなインデックス、aggregationvやその他の操作などの他は、ありますが、また、これらのいくつかのシーンの性質に依存します。

ステップ3：サービスのキャパシティ・アセスメント

この2つのステップの後、データベース全体を検索することは非常に合理的であることがわかり、すべての要求を効率的にインデックス、最適化のための基本的余地なくなっている、あなたのマシンがサービス容量の上限に達している、あなたが設定をアップグレードする必要があると思われます（または延長シャーディングによって）。

もちろん、最良の環境は、むしろ完全なリソースを持つCPUに比べて、アップグレード、あなたのシーンでタイムリーな拡張の上限に対応するサービス能力を知るためにMongoDBのテストに進む時は、ビジネスは、に行く前にやっと完全あり評価を行います。

出典ます。https：//www.ywnds.com/のp = 9010？

出典：Zhangyouドンさんのブログ

MongoDBのCPU使用率が高い、破るためにどのように（ターン）

おすすめ