0

3 つの MongoDB インスタンスのレプリカ セットがあります。インスタンスには 8 GB の RAM とデュアル コア 2.27 GHz CPU が搭載されています。すべてのインスタンスはバージョン 2.2.2 を実行しています (2.0.1 から同じ動作を見ました)。

これが私の問題です: 私たちのプライマリ インスタンス (レプリカ セットのマスター) は最近、2 日ごとに 100% の CPU までクロールする習慣を身につけました。原因を突き止めた結果、MongoDB プロファイラーを実行することにしました。何百もの非常に遅いクエリが見つかりました。次に例を示します。

> db.system.profile.find()
{ 
    "ts" : ISODate("2012-12-16T20:31:39.078Z"), 
    "op" : "command", 
    "ns" : "stylesaint.$cmd", 
    "command" : { 
        "count" : "tears", 
        "query" : { 
            "_id" : { "$gt" : ObjectId("50cdeadeaf58d3de96000294") }, 
            "active" : true, 
            "is_image_processed" : true, 
            "hidden_from_feed" : false, 
            "hidden_from_public_feeds" : false
        }, 
        "fields" : null 
    }, 
    "ntoreturn" : 1, 
    "responseLength" : 48, 
    "millis" : 13930, 
    "client" : "#########"
}

私がmongodbについて読んだことから、これらの状況での自然な次のステップは、これらのクエリをexplain()することです。ただし、explain() はクエリの遅さを説明しません。

> db.tears.find({ "_id" : { "$gt" : ObjectId("50cdeadeaf58d3de96000294") }, "active" : true, "is_image_processed" : true, "hidden_from_feed" : false, "hidden_from_public_feeds" : false }).explain()
{
    "cursor" : "BtreeCursor id",
    "isMultiKey" : false,
    "n" : 4,
    "nscannedObjects" : 5,
    "nscanned" : 5,
    "nscannedObjectsAllPlans" : 23,
    "nscannedAllPlans" : 25,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 0,
    "indexBounds" : { 
        "_id" : [ 
            [ 
                ObjectId("50cdeadeaf58d3de96000294"), 
                ObjectId("ffffffffffffffffffffffff")
            ]
        ]
    },
    "server" : "#########"
}

5 つのドキュメントをスキャンするのに 13 秒もかからないはずです。クエリを遅くしている何か他のことが起こっています。他のクエリがサーバーのリソースを枯渇させている可能性がありますか? とはいえ、どこを見ればいいのかわからない。アドバイスをいただければ幸いです。

MongoDB ログ

起動プロセスで警告が見つかりませんでした:

***** SERVER RESTARTED *****


Sun Dec 16 21:02:56 [initandlisten] MongoDB starting : pid=...
Sun Dec 16 21:02:56 [initandlisten] db version v2.2.2, pdfile version 4.5
Sun Dec 16 21:02:56 [initandlisten] git version: ...   
Sun Dec 16 21:02:56 [initandlisten] build info: Linux 2.6.21.7-2 ...
Sun Dec 16 21:02:56 [initandlisten] options: { config: "/etc/mongodb.conf", dbpath: "/data/mongodb", logappend: "true", logpath: "/var/log/mongodb/mongodb.log", replSet: "...", rest: "true" }
Sun Dec 16 21:02:56 [initandlisten] journal dir=/data/mongodb/journal
Sun Dec 16 21:02:56 [initandlisten] recover : no journal files present, no recovery needed
Sun Dec 16 21:02:56 [initandlisten] waiting for connections on port ...
Sun Dec 16 21:02:56 [websvr] admin web console waiting for connections on port ...
Sun Dec 16 21:02:56 [initandlisten] connection accepted from ...
Sun Dec 16 21:02:56 [conn1] end connection ... (0 connections now open)
Sun Dec 16 21:02:56 [initandlisten] connection accepted from ... #2 (1 connection now open)
Sun Dec 16 21:02:56 [rsStart] replSet I am ...
Sun Dec 16 21:02:56 [rsStart] replSet STARTUP2
Sun Dec 16 21:02:56 [rsHealthPoll] replSet member ... is up
Sun Dec 16 21:02:56 [rsHealthPoll] replSet member ... is now in state SECONDARY
Sun Dec 16 21:02:57 [initandlisten] connection accepted from ... #3 (2 connections now open)
Sun Dec 16 21:02:57 [rsSync] replSet SECONDARY
Sun Dec 16 21:02:58 [initandlisten] connection accepted from ... #4 (3 connections now open)
Sun Dec 16 21:02:58 [initandlisten] connection accepted from ... #5 (4 connections now open)
Sun Dec 16 21:02:58 [conn5] end connection ... (3 connections now open)
Sun Dec 16 21:02:58 [rsHealthPoll] replSet member ... is up
Sun Dec 16 21:02:58 [rsHealthPoll] replSet member ... is now in state PRIMARY
Sun Dec 16 21:02:59 [initandlisten] connection accepted from ... #6 (4 connections now open)
Sun Dec 16 21:03:00 [initandlisten] connection accepted from ... #7 (5 connections now open)
Sun Dec 16 21:03:02 [conn7] end connection ... (4 connections now open)
Sun Dec 16 21:03:03 [rsBackgroundSync] replSet syncing to: ...
Sun Dec 16 21:03:04 [rsSyncNotifier] replset setting oplog notifier to ...
Sun Dec 16 21:03:06 [conn2] end connection ... (3 connections now open)
Sun Dec 16 21:03:06 [initandlisten] connection accepted from ... #8 (4 connections now open)
Sun Dec 16 21:03:08 [initandlisten] connection accepted from ... #9 (5 connections now open)
Sun Dec 16 21:03:13 [initandlisten] connection accepted from ... #10 (6 connections now open)
Sun Dec 16 21:03:13 [conn10] end connection ... (5 connections now open)
Sun Dec 16 21:03:13 [initandlisten] connection accepted from ... #11 (6 connections now open)
Sun Dec 16 21:03:15 [conn3] end connection ... (5 connections now open)
Sun Dec 16 21:03:16 [rsHealthPoll] replSet member .... is now in state SECONDARY
Sun Dec 16 21:03:16 [rsMgr] replSet info electSelf 1
Sun Dec 16 21:03:16 [rsMgr] replSet PRIMARY

Re: 詳細のリクエスト

現時点では、MongoDB は正常に機能しています。100 ミリ秒を超えるクエリはありません。CPU が 100% に戻ったらすぐに、システム リソースに関する詳細情報を投稿します。

4

1 に答える 1

0

まず、クエリはおそらくニシンだと思います。これらのサーバーを NUMA アーキテクチャで実行していますか? NUMA システムでの使用法については、Mongo のドキュメントを参照してください。

NUMA システムで実行している場合は、numactl を使用してインターリーブ ポリシーでデーモンを実行すると、問題が解決する可能性があります。

起動警告があるかどうかを確認できます。それらは、デーモンの起動中にログに表示され、後でデーモンの実行中にそれらを見つけることができますが、頭のてっぺんからどのように思い出したかは覚えていません.

そうしないと、これらのクエリを作成しながら IO 操作を確認できます。私が推測しなければならなかった場合、あなたはディスクを叩いていて、メモリ内のワーキングセットで操作していません. メモリ使用統計 (free -h と mongo コンソール内からのメモリ使用メトリック) はどのように見えますか?

于 2012-12-18T00:33:24.313 に答える