阿里雲アカウント販売: MongoDBインスタンスの接続プールがいっぱいになったことと、インデックスが作成されていないことによるスロークエリブロックのトラブルシューティング

サイトSEOの最適化と性能調整の過程で、私は多くの驚くべき「事故」に遭遇したことがある。突然、APIインタフェースの応答時間が数秒から十数秒に上昇し、その後、フロントエンドは大量の504 Gateway Timeoutをスローし、検索エンジンSpider (例えばGooglebot、vbbot) の獲得成功率は瞬時に雪崩した。

SEOサイト最適化師として、データベースの性能がサイトSEOに与える致命的な影響を知っています。検索エンジンはページロード速度(TTFB、LCPなどCore Web Vitals指標) に対する要求が極めて厳しい。データベースにカールトンが現れて、フロントエンドのインターフェースがタイムアウトした場合、検索エンジンはあなたのサイトの「信頼できない」を迅速に判定し、直接に捕獲頻度をカットして、収録の一時停止とキーワードランキングの断崖的な低下を引き起こす。

使っています

Alibaba cloud ApsaraDB for MongoDB

このような性能災害を引き起こす最も一般的な「元凶」は

インデックスが作成されていないため、スロークエリと接続プールがいっぱいになったことによる連鎖ブロック

。

今日、私は実戦調査、原理分析からコードとアーキテクチャの最適化まで、この問題を徹底的に調査し、解決する方法を説明します。

一、なぜ「インデックスが作成されていない」と瞬時に「接続プール」が爆発するのか?

問題を解決するには、まず両者の間の

雪だるま効果 (雪崩効果)

。

1. 全表スキャン (colscan) がCPUとI/Oを使い果たした

アプリケーションがMongoDBにクエリ要求を開始したとき (ユーザーid、記事分類、ラベル検索など) 、対応するフィールドが

インデックスが作成されていません

MongoDBは実行しなければなりません。

COLLSCAN

(全表スキャン)

ディスク上のコレクション全体を1つずつ読み取って比較する必要があります。集合に数十万から数百万のデータがあると、一度のクエリで大量のCPU計算リソースとディスクI/Oを消費する。

2.遅い照会が接続にひっかかって、接続プールが急速に爆発した

Node.js、Java Spring Boot、Python DjangoなどのWebフレームワークは、通常、データベース接続プールを使用して接続を再利用します。

正常状況: 1つのクエリが2ミリ秒で完了し、接続が解放され、接続プールに回収され、次の要求に使用されます。

異常状況: インデックスが作成されていない遅いクエリが完了するまでに3秒かかります。この3秒で、この接続は独占されます。

雪崩が始まった: ユーザーがエンジンSpiderを訪問したり検索したりするにつれて、新たな要求が次々と流れ込んできた。前の接続はすべて遅いクエリにひっかかっているので、新しい要求は新しいものを作るしかないです。

接続します。ごく短時間で、接続数はアプリケーション層または阿里雲MongoDBインスタンス仕様ライセンスの上限に達する。

最終的に、接続プールが完全にいっぱいになり、その後、データベース接続を取得しようとするすべての要求がスローされます

Timeout waiting for connection from pool

、全駅業務が麻痺した。

二、第一歩: 阿里雲コンソールと命令を利用して「遅いクエリ」を迅速に特定する方法

接続プールが警告された場合、Webサービスを盲目的に再起動したり、MongoDBインスタンスの構成をアップグレードしたりすると、多くの場合、治標は根本的ではない。次の標準化プロセスに従って「罪の首謀者」を正確に特定する必要があります。

1.阿里雲MongoDBコンソール「スローログ」機能を使用する

Alibaba cloud MongoDBコンソールにログインします。

上部ナビゲーションバーでインスタンスが存在する地域を選択し、ターゲットインスタンスIDをクリックします。

左側のメニューバーで、クラウド監視とログ-> スローログ (またはログ管理) を選択します。

トラブルシューティングの時間範囲 (業務エラーの開始時点) を設定し、Execution Time (実行時間): 100msを超えるクエリは警戒する必要がある千ミリ秒以上は致命的な遅いクエリです。ドキュメントの数とドキュメントの数を返します。これは典型的なインデックス不足の特徴です!

運送次元とインフラのヒント: クラウドデータベースのパフォーマンスをチェックし、仕様の一時的な変更 (CPU/メモリを増やして緊急止血するなど) やログサービス (SLS) を開設して深いログ検索を行う場合必ずアカウントの維持状態を正常に維持してください。日常運送の平和維持と枠組みの調整で、予算計画を立てて、阿里雲口座番号のチャージを完成して、口座の残高が十分であることを確保することを提案する。これにより、費用不足でコンソールの高度な監視機能が制限され、バックアップが中断され、クラウドデータベースが強制的にダウングレードされたり、ロックされたりして、トラブルシューティングの黄金の救急時間に影響を与えることを避けることができる。

2.MongoDBにログインして実行する

Mr top ()

診断リアルタイムブロック

MongoDBデータベースの読み書き権限がある場合は、MongoシェルまたはData Management Service (DMS) を介してデータベースに直接ログインし、次のコマンドを実行して、現在実行中で時間のかかる操作を確認できます

JavaScript

// クエリの実行時間が2秒を超え、実行中の非システム操作

Db.currentOp({

「アクティブ」: true、

"Secs_ning": {"$ gt": 2 },

"Ns": {

"$ Ne": "local.oplog.rs"}

})

返された結果で、次のことに焦点を当てます

プランサマリー: collescanと表示された場合、文は全表スキャンを行っていることを示します。

Client: この遅いクエリを開始するアプリケーションサーバのipアドレス。

Command: 具体的なクエリJSON文。

三、第二ステップ: スロー検索の診断とインデックス最適化実戦

具体的な遅いクエリ文を特定した後、MongoDBの

Explain ()

アナライザはそれを診断し、正確にインデックスを作成します。

1. 使用

Explain (「execution stats」)

照会計画の分析

DMSまたはクライアントツールでは、遅いクエリ文の後に

.Explain ("execution stats")

:

JavaScript

Db.Hex.find({ "category": "seo", "status": "published" }).sort({ "created _at": -1 }).explain("execution stats")

出力結果の中心的な指標に注目するには:

Stage: colscanの場合は、インデックスを付ける必要がありますIXSCANの場合は、インデックスが使用されています。

カレントdocくすみ: スキャンしたドキュメントの総数。

NReturned: 実際にマッチしたドキュメントの数。理想的な状態では、totaldocsexamiedはできるだけnReturnedに近づく必要があります。

Stage: 「SORT」: この段階が発生した場合、MongoDBはメモリ内でハードソートを行い、データ量が多い場合にもCPUを非常に消費することを示している。

2.ESRの原則に従って複合インデックスを構築する

複数条件のクエリとソートされたシーンでは、複合インデックスを作成するには

ESRの原則

:

E-テンションマッチ (等値マッチ): 正確に検索するフィールドを配置します。

S - Sort (ソート): sort() に使用するフィールドを配置します (例: -1)。

R - Range (範囲クエリ): 範囲検索のフィールドを配置します。

インデックス作成の例:

JavaScript

// 文章集合のためにESRの原則に合致した複合索引を作成する

Db.18:30.createIndex (

{"Status

": 1, "created _at ": -1," view ": 1 },

{Background: true, name: "idx _ status _ created _ view"}

）

注意: 本番環境でインデックスを作成するには、 {background: true }(MongoDB 4.2バージョンではデフォルトでバックグラウンド最適化されて構築されています) を追加して、インデックス作成プロセスロックテーブルが新しいカールトンを起こさないようにすることをお勧めします。

四、第三ステップ: 接続池のパラメータ調整と雪崩防止メカニズム

インデックスの問題を解決した後、アプリケーション層に合理的なデータベース接続プールパラメータを構成して、将来的に突発的なトラフィックで接続プールが再び満杯になるのを防ぐ必要があります。

1. 科学的構成アプリケーション層接続プールサイズ (Max Pool Size)

多くの開発者は「接続プールを大きく設定すればするほどいい」と勘違いしていますが、これは実は大きな誤植です。盲目の将

MaxPoolSize

500から1000に設定すると、大量のサーバメモリを消費するだけでなく、CPUが頻繁にコンテキストスイッチを行うため、全体のスループットが低下します。

推奨式: maxconnect = (CPUコア数 * 2) ディスク同時数

一般的なアプリケーション構成: 単一のWebアプリケーションノードがmaxpool sizeを20 ~ 50に設定すると、通常、高同時処理に対応するのに十分です。複数のアプリケーションノードがある場合、すべてのノードのmaxPoolSizeの和が阿里雲MongoDBインスタンス仕様でサポートされている最大接続数より小さいことを保証する必要がある。

Node.js Mongooseを例にした推奨接続構成:

JavaScript

Const mongoose = require('mongoose');

Const options = {

MaxPoolSize: 30、 // 最大接続数を制限し、データベースがいっぱいにならないようにします

MinPoolSize: 5、 // 最小アイドル接続数を維持する

Serverselect timeoutms: 5000, // 使用可能なサーバータイムアウト時間を探す (5秒)

SocketTimeoutMS: 0.000、 // ソケット読み書きタイムアウト時間

ファミリー: 4 // 強制的にIPv4を使用する

};

Mongoose.connect('mongodb:// root:[email protected]

Om: 3717/admin?replicaSet = mgset-xxx ', options);

2.タイムアウトと溶断保護の導入

アプリケーション層でデータベース照会を開始するときは、必ず合理的なタイムアウト時間を設定してください (例:

MaxTimeMS

) 、複雑なクエリが発生しても、無期限に接続プールにひっかかるのではなく、指定した時間内に例外をスローして接続を解放できるようにします。

JavaScript

// 1回のクエリの最大実行時間を2000ミリ秒に制限する

Db.Hex.find({ category: "seo" }).maxTimeMS(2000);

五、SEOサイト最適化師のまとめ: 性能はSEOの生命線である

SEOサイトの最適化師として、私はよく言います

技術の基盤とロード速度を離脱したSEOはすべて空中楼閣である。

」

守護検索エンジンが予算をつかむ (Crawl Budget): MongoDBがインデックスと接続プールがいっぱいになったため、インタフェースが頻繁にタイムアウトした (504) と、検索エンジンSpiderのキャプチャ効率が大幅に低下する。ゆっくりとしたクエリを整理し、接続プールを最適化することで、webサイトのインタフェースにミリ秒レベルの応答を維持し、検索エンジンのキャプチャ量と収録速度を直接向上させることができる。

Core Web Vitalsの体験を保障する: 高速なデータベース応答はTTFB (最初のバイト時間) を下げる根本である。ページのレンダリングが速いほど、ユーザーのジャンプ率が低くなり、検索エンジンでのページの総合的な重みが高くなります。

クラウドのインフラ管理を重視する: データベースの調整は、コードを書いたりインデックスを作ったりするだけでなく、クラウド資源の日常的な微細化輸送にも表れている。MongoDB規格の拡張、DAS (データベースデータベース自動調整サービス) やログ監査を行う際に、良好な予算計画と阿里雲アカウントのチャージ習慣を維持しクラウド監視警報とデータベース自治サービスが常にオンラインであることを確保し、未然に防ぐことができる。

通過する

スローログの位置付け-> explain() 解析-> ESRインデックス作成-> 接続プールパラメータの最適化

「この基準は閉ループをチェックすると、阿里雲MongoDBの遅いクエリのブロックと接続プールがいっぱいになった頑固な病気を徹底的に解決して、webサイトのために迅速で安定した基礎データベースアーキテクチャを構築することができます!