Тупик при обновлении MongoDb

Можно ли зайти в тупик при операциях обновления MongoDb? Я выполняю нагрузочный тест для операции обновления, которая выглядит так:

db.update(
    { foo: {a: 'xxx', b: 'yyy'}, $lt: {"order.date": someDate}}, 
    {order: order}, 
    true, false);

Развернут на машине Azure с официальным драйвером mongodb C #. Единичный экземпляр, пока нет наборов реплик или сегментирования.

Когда я запускаю 5000 этой же команды обновления, разделенную между 200 параллельными потоками (2 машины по 100 потоков каждая), в большинстве случаев это заканчивается взаимоблокировками. Т.е. многие звонки никогда не возвращаются. Я вижу из db.currentOp () через консоль, многие обновления все еще там, застряли в заблокированном: true, с lockType: 'write'.

Почему возникает этот тупик? Как это возможно? И как мне это предотвратить? Есть ли какие-либо конкретные рекомендации о том, каких операций следует избегать, чтобы избежать взаимоблокировок на mongodb?

Связан ли $ atomic с решением? Я даже не знаю, как установить $ atomic: true в C #, хотя, вероятно, это не имеет отношения к этой проблеме тупика.


multithreading c# mongodb deadlock upsert
person Sheepy    schedule 14.10.2011    source источник
comment
Upsert - это операция обновления?   -  person sll    schedule 14.10.2011
comment
это обновление с флагом upsert, установленным в значение true   -  person Sheepy    schedule 18.10.2011

Ответы (1)


arrow_upward
0
arrow_downward

$ atomic должен помочь

db.update(
    {
        $and: [
            { foo: { a: 'xxx', b: 'yyy' },
            { $lt: { 'order.date': someDate } }
        ],
        $atomic: true
    },
    { order: order },
    true,
    false
);

также вам может потребоваться предложение $ и. проверьте объяснение своего звонка, чтобы узнать, какие индексы используются и т. д.

person ZagNut    schedule 23.04.2012