3

同時読み取りを持つコレクションと、同じコレクションを更新するアプリケーションの一部がありますが、ロード中に各読み取りおよび更新操作に非常に時間がかかり、時間とともに非常に遅くなります

ここにいくつかのクエリのログがあります

nscanned:4 nupdated:2 keyUpdates:3 numYields: 1 locks(micros) w:2475463 10247ms
nscanned:4 nupdated:2 keyUpdates:2 numYields: 1 locks(micros) w:2077481 1054ms

コレクションには 70K レコードしかありません。同時読み取りと書き込みはほぼ 10 です。

これは私がすでにやったことです

  1. 3 メンバーのレプリカ セットによるシャーディング

  2. シャーディング キーはハッシュされ、データベース レベルとコレクション レベルの両方のシャーディングが有効になります

  3. 各レプリカボックスには十分なパワーとRAMがあります。

  4. クエリはインデックスでバインドされてdb.collection.find().explain()おり、この出力があります

    {
    "cursor" : "BtreeCursor fp.ulc_1_c_1_p_1",
    "isMultiKey" : true,
    "n" : 0,
    "nscannedObjects" : 2,
    "nscanned" : 2,
    "nscannedObjectsAllPlans" : 2,
    "nscannedAllPlans" : 2,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 0,
    "indexBounds" : {
        "fp.ulc" : [
            [
                "0ca01c47c984b5583d455e42aafded2c",
                "0ca01c47c984b5583d455e42aafded2c"
            ]
        ],
        "c" : [
            [
                false,
                false
            ]
        ],
        "p" : [
            [
                1372062247612,
                1.7976931348623157e+308
            ]
        ]
    }
}

また、セカンダリで読み取り設定を設定しようとしましたが、しばらくすると遅くなります また、mongostat のロックが mongostat から出力されることにも気付きました

insert  query update delete getmore command flushes mapped  vsize    res faults       locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn  set repl       time
    *0     *0      6     *0       4     2|0       0  54.4g   109g  1.74g      0 collectDb:199.7%          0       6|0     0|1     3k   130k    21 set1  PRI   08:27:55
    *0     *0     15     *0      11     8|0       1  54.4g   109g  1.74g      0 collectDb:200.1%          0       6|0     0|1    11k   357k    21 set1  PRI   08:27:58
     7     *0     34     *0      18    26|0       0  54.4g   109g  1.75g      0 collectDb:202.9%          0       6|0     0|1    36k   362k    21 set1  PRI   08:28:00
     1     *0     13     *0       8     7|0       0  54.4g   109g  1.75g      0 collectDb:192.3%          0       6|0     0|1    12k   287k    21 set1  PRI   08:28:03
     1     *0      9     *0       7     8|0       0  54.4g   109g  1.75g      0 collectDb:196.1%          0       6|0     0|1     5k   258k    21 set1  PRI   08:28:04
     5     *0     20     *0      10    13|0       0  54.4g   109g  1.75g      0 collectDb:207.7%          0       6|0     0|1    23k   214k    21 set1  PRI   08:28:08
     8     *0     38     *0      21    29|0       0  54.4g   109g  1.74g      0 collectDb:215.9%          0       5|0     0|1    40k   548k    21 set1  PRI   08:28:12
     6     *0     44     *0      24    22|0       0  54.4g   109g  1.75g      0 collectDb:199.5%          0       3|0     0|1    45k   509k    21 set1  PRI   08:28:15
     2      4     27     *0      11    28|0       0  54.4g   109g  1.75g      0 collectDb:169.2%          0       6|0     0|1    21k   318k    21 set1  PRI   08:28:18
     2     *0     29     *0      18    20|0       0  54.4g   109g  1.74g      0 collectDb:255.5%          0       5|0     0|1    28k   588k    21 set1  PRI   08:28:24
4

1 に答える 1

3

それで、mongodbでのロックを回避するための最良の方法を最終的に見つけました。

私がしたこと

  • hereからmongodbを最新の安定した製品リリース2.4.8に更新しました。

  • Raid 10 ebsで ebs を最適化された iops 2000 に更新しました。

  • mongod.log ファイルから遅いクエリを監視し、各ドライブの iowait も監視しました。

  • Mongodb indexs docs からいくつかのマルチキー インデックスと複合インデックスを追加しました。

  • また、レプリカ セットのプライマリおよびセカンダリ メンバーを含む各 ec2 インスタンスでの RAM の消費も監視しました。

  • インスタンスタイプをギガビット イーサネット インターフェイスで最適化された Ebs に変更し、各サーバーで 16 GB 以上の RAM を使用して、ほとんどの時間 RAM をインデックスと現在のデータ セットに使用できるようにします。

  • 要件をよりよく理解できるように、Amazon インスタンスとその最適なユース ケースのドキュメントを読むことをお勧めします。

ロックは MongoDB の主要な問題ですが、コレクション レベルのロックに取り組んでいると思いますので、今後のバージョンでは、ロックによるパフォーマンスの低下に関連するほとんどすべてが解決される可能性があります。ステータスを確認できるjiraリンクは次のとおりです。

于 2014-01-09T22:19:11.140 に答える