2012-02-23 9 views
4

我々はMongoDBの私たちの最初の使用に問題があります:)ここではいくつかの事実されていますMongoDBの低スループットの非常に高いロック率

  • 95 +%ロック割合
  • サーバは2コアを搭載したVMであります、6 GB RAM、mongodb用の高速NAS上にNFS v3共有(noatime)
  • のCentOS 5.7 x86_64版、モンゴ2.0.2、PHP-PECL-モンゴ1.2.6(最新版ではないが、すぐにアップデートします:)
  • Mongoのは(現在/誤って)スレーブ
  • せずに単一のマスターとして設定されていますdbは今日からゼロから作成されました。 (更新を使用して)
  • サーバーに送信された更新の数は不明ですが、処理される量は非常に少ない
  • インデックスの問題かどうかわかりません。診断する? (oplog、ジャーナル...を含む)
  • 現在のディスクデータ未満600メガバイト
  • DSTATある:
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- 
usr sys idl wai hiq siq| read writ| recv send| in out | int csw 
46 1 53 0 0 0| 0 4096B| 42k 19k| 0  0 | 317 5328 
48 1 52 0 0 1| 0 92k| 46k 7590B| 0  0 | 321 5308 
50 2 48 0 0 0| 0  0 | 39k 7218B| 0  0 | 304 5359 
47 1 51 0 0 1| 0  0 | 47k 10k| 0  0 | 332 5679 
46 1 52 0 0 0| 0  0 | 44k 15k| 0  0 | 319 5099
  • nfsiostatは空である(0 OPS /秒​​)(コースIOSTATのあります
  • )同じmongostat:
insert query update delete getmore command flushes mapped vsize res faults locked % idx miss %  qr|qw ar|aw netIn netOut conn repl  time 
    0  0  0  0  0  1  0 1.41g 8.39g 242m  0  96.2   0 0|3280 1|5322 62b  1k 5324 M 21:11:50 
    0  0  0  0  0  1  0 1.41g 8.39g 242m  0  96.5   0 0|3204 1|5322 62b  1k 5324 M 21:11:51 
    0  0  0  0  0  1  0 1.41g 8.39g 242m  0  96   0 1|3351 1|5322 62b  1k 5324 M 21:11:52 
    0  0  1  0  0  1  0 1.41g 8.39g 242m  0  96.9   0 0|3251 1|5322 485b  1k 5324 M 21:11:53 
    0  0  0  0  1  1  0 1.41g 8.39g 242m  0  95.6   0 0|3280 1|5322 112b  1k 5324 M 21:11:54
  • db.serverStatus()
{ 
     "host" : "foo001", 
     "version" : "2.0.2", 
     "process" : "mongod", 
     "uptime" : 21370, 
     "uptimeEstimate" : 18626, 
     "localTime" : ISODate("2012-02-23T20:20:59.589Z"), 
     "globalLock" : { 
       "totalTime" : 21369761258, 
       "lockTime" : 19450568051, 
       "ratio" : 0.9101911722911022, 
       "currentQueue" : { 
         "total" : 3570, 
         "readers" : 0, 
         "writers" : 3570 
       }, 
       "activeClients" : { 
         "total" : 5500, 
         "readers" : 1, 
         "writers" : 5499 
       } 
     }, 
     "mem" : { 
       "bits" : 64, 
       "resident" : 255, 
       "virtual" : 8782, 
       "supported" : true, 
       "mapped" : 1440, 
       "mappedWithJournal" : 2880 
     }, 
     "connections" : { 
       "current" : 5501, 
       "available" : 4099 
     }, 
     "extra_info" : { 
       "note" : "fields vary by platform", 
       "heap_usage_bytes" : 81930736, 
       "page_faults" : 2916 
     }, 
     "indexCounters" : { 
       "btree" : { 
         "accesses" : 2377, 
         "hits" : 2377, 
         "misses" : 0, 
         "resets" : 0, 
         "missRatio" : 0 
       } 
     }, 
     "backgroundFlushing" : { 
       "flushes" : 356, 
       "total_ms" : 2372, 
       "average_ms" : 6.662921348314606, 
       "last_ms" : 0, 
       "last_finished" : ISODate("2012-02-23T20:20:56.446Z") 
     }, 
     "cursors" : { 
       "totalOpen" : 5500, 
       "clientCursors_size" : 5500, 
       "timedOut" : 0, 
       "totalNoTimeout" : 5499 
     }, 
     "network" : { 
       "bytesIn" : 51373772, 
       "bytesOut" : 51176411, 
       "numRequests" : 176017 
     }, 
     "repl" : { 
       "ismaster" : true 
     }, 
     "opcounters" : { 
       "insert" : 0, 
       "query" : 25, 
       "update" : 142157, 
       "delete" : 0, 
       "getmore" : 39053, 
       "command" : 284 
     }, 
     "asserts" : { 
       "regular" : 0, 
       "warning" : 0, 
       "msg" : 0, 
       "user" : 0, 
       "rollovers" : 0 
     }, 
     "writeBacksQueued" : false, 
     "dur" : { 
       "commits" : 19, 
       "journaledMB" : 0, 
       "writeToDataFilesMB" : 0, 
       "compression" : 0, 
       "commitsInWriteLock" : 0, 
       "earlyCommits" : 0, 
       "timeMs" : { 
         "dt" : 3083, 
         "prepLogBuffer" : 0, 
         "writeToJournal" : 0, 
         "writeToDataFiles" : 0, 
         "remapPrivateView" : 0 
       } 
     }, 
     "ok" : 1 
}
  • 当社デシベル:
{ 
     "db" : "mydb", 
     "collections" : 6, 
     "objects" : 119174, 
     "avgObjSize" : 323.99872455401345, 
     "dataSize" : 38612224, 
     "storageSize" : 57286656, 
     "numExtents" : 26, 
     "indexes" : 4, 
     "indexSize" : 3899952, 
     "fileSize" : 469762048, 
     "nsSizeMB" : 16, 
     "ok" : 1 
}

任意のヒント?

よろしく、

D.

PS:私もこのモンゴ・ユーザーのために

+0

更新操作はどのように見えますか?正確なデータを省略することはできますが、使用されている演算子と結合されている演算子の数の考え方を参考にしてください。また、どのフィールドがインデックスに登録されていますか? – mattbornski

+0

状況を解決するために行ったことのフォローアップを投稿できますか?フォローアップへのリンク。 –

答えて

4

mongostat結果によると、あなたが書き込みをキューイングされている(QRをチェッククロスポスト|、QW第2の値をあなたのシステムが新しい書き込みが来る前に書き込むのに十分速くないことを意味します)。

あなたのmongostatによると、書き込みは多くありませんが、それぞれ遅いです。問題は更新されているようです。多分findAndModifyを使用していますか?それは複雑なクエリを使用している場合、DBをしばらくロックします。 おそらくあなたがmongostatに書いた情報は、巨大なスパイクの書き込みの後でした。とにかく、それらはおそらく非常に遅いですか、その高いロックが表示されません(キューに書き込まれた書き込みはすぐに減少します)。

DBプロファイラをアクティブにして更新を分析する必要があります。詳細はthis pageを確認

PDは:インデックスのサイズは、罰金になりますです

"indexes" : 4, 
    "indexSize" : 3899952, 

メガバイト

未満4 EDITED:かなりの数の書き込みクライアントが存在するような別の詳細は、それが見えます同時に接続されます。 Webサーバーが20台ある場合は、それぞれが複数回接続している可能性があります。

"activeClients" : { 
        "total" : 5500, 
        "readers" : 1, 
        "writers" : 5499 
        } 
5

くださいは、データベースのバックエンドとしてNFSを使用しないでくださいしてください。非常に多くの問題があります。特にとロックあり特にのNFS < v4です。そして、彼らはではないので、ちょうどのパフォーマンスの問題では、NFSはおそらく考慮されるべきではありません。

私はローカルディスクに私のDBを移動し始めて、それがパフォーマンスの問題を解決するかどうかを確認でしょう - 私はそれが意志を疑ういる...

EDIT:

MongoDBの人にもseem to agree、やや簡潔であれば、そのNFSはではなく、が推奨されます。

+0

いいえ、NFSをデータベースバックエンドのオプションにしないでください – Khelben

+0

NFSがMongoで使用するように提案されていない場合、ドキュメントを集中管理するための良い解決策はありますか? crontabbed rsyncスクリプト? –

関連する問題