Как избежать блокировки в mongodb

Question

У меня есть коллекция, которая одновременно читает, а также часть приложения, обновляющего одну и ту же коллекцию, но во время загрузки каждая операция чтения и обновления занимает так много времени, и со временем она становится очень медленной

---

Вот лог некоторого запроса

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 

Коллекция имеет только 70К записей. Параллельное чтение и запись почти 10.

Это то, что я уже сделал

1. Sharding с 3 члена реплики набор

2. ключ Sharding хешируется и как БД и коллекции уровень Sharding является enble

3. В каждой коробке с репликами достаточно мощности и бара.

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 

Answer 1

Так я наконец понял, какой лучший способ избежать блокировки в MongoDB.

Что я сделал

• Обновленный мой MongoDB для выпуска последней стабильной производственной 2.4.8 from here.

• Обновлен мой ebs для оптимизированного iops 2000 с Raid 10 ebs.

• Отслеживал мои медленные запросы от файла mongod.log, а также iowait для каждого диска.

• Добавлен ряд индексных индексов и индексных индексов From Mongodb indexs docs.

• А также я наблюдал за потреблением бара на каждом экземпляре ec2, включая первичный и вторичный элементы набора реплик.

• Change the instance тип Ebs оптимизирован с интерфейсом Gigabit Ethernet и более 16 ГБ оперативной памяти на каждом сервере, так что большая часть таймера времени доступна для индекса и текущего набора данных.

• Полезно читать Documentation для экземпляра amazon и их наилучшего варианта использования, чтобы вы могли лучше понять свое требование.

---

Хотя замок является главной проблемой в MongoDB, но я думаю, что они работают на замок уровня сбора так может быть в следующей версии будет решить практически все, что связано с ухудшением качества производительности из-за блокировки. Вот ссылка jira, Вы можете проверить статус.