2011-12-20 9 views
6

MongoDBでFindAndModifyをいくつかの並行プロセスで使用しています。コレクションのサイズは約300万エントリで、インデックス化されたフィールドによる並べ替えオプションを渡さない限り、すべてが爆発的に機能します。私はそうしようとすると、次の警告がログに起動されます:MongoDB FindAndModifyソート

warning: ClientCursor::yield can't unlock b/c of recursive lock ns: test_db.wengine_queue top: 
{ 
opid: 424210, 
active: true, 
lockType: "write", 
waitingForLock: false, 
secs_running: 0, 
op: "query", 
ns: "test_db", 
query: { 
    findAndModify: "wengine_queue", 
    query: { 
      locked: { $ne: 1 }, 
      rule_completed: { $in: [ "", "0", null ] }, 
      execute_at: { $lt: 1324381363 }, 
      company_id: 23, 
      debug: 0, 
      system_id: "AK/AK1201" 
     }, 
    update: { 
      $set: { locked: 1 } 
     }, 
    sort: { 
      execute_at: -1 
     } 
}, 
client: "127.0.0.1:60873", 
desc: "conn", 
threadId: "0x1541bb000", 
connectionId: 1147, 
numYields: 0 
} 

は私がインデックス化クエリからすべてのキーを持っている、ここで彼らは、次のとおりです。

PRIMARY> db.wengine_queue.getIndexes() 
[ 
{ 
    "v" : 1, 
    "key" : { 
     "_id" : 1 
    }, 
    "ns" : "test_db.wengine_queue", 
    "name" : "_id_" 
}, 
{ 
    "v" : 1, 
    "key" : { 
     "system_id" : 1, 
     "company_id" : 1, 
     "locked" : 1, 
     "rule_completed" : 1, 
     "execute_at" : -1, 
     "debug" : 1 
    }, 
    "ns" : "test_db.wengine_queue", 
    "name" : "system_id_1_company_id_1_locked_1_rule_completed_1_execute_at_-1_debug_1" 
}, 
{ 
    "v" : 1, 
    "key" : { 
     "debug" : 1 
    }, 
    "ns" : "test_db.wengine_queue", 
    "name" : "debug_1" 
}, 
{ 
    "v" : 1, 
    "key" : { 
     "system_id" : 1 
    }, 
    "ns" : "test_db.wengine_queue", 
    "name" : "system_id_1" 
}, 
{ 
    "v" : 1, 
    "key" : { 
     "company_id" : 1 
    }, 
    "ns" : "test_db.wengine_queue", 
    "name" : "company_id_1" 
}, 
{ 
    "v" : 1, 
    "key" : { 
     "locked" : 1 
    }, 
    "ns" : "test_db.wengine_queue", 
    "name" : "locked_1" 
}, 
{ 
    "v" : 1, 
    "key" : { 
     "rule_completed" : 1 
    }, 
    "ns" : "test_db.wengine_queue", 
    "name" : "rule_completed_1" 
}, 
{ 
    "v" : 1, 
    "key" : { 
     "execute_at" : -1 
    }, 
    "ns" : "test_db.wengine_queue", 
    "name" : "execute_at_-1" 
}, 
{ 
    "v" : 1, 
    "key" : { 
     "thread_id" : 1 
    }, 
    "ns" : "test_db.wengine_queue", 
    "name" : "thread_id_1" 
}, 
{ 
    "v" : 1, 
    "key" : { 
     "rule_id" : 1 
    }, 
    "ns" : "test_db.wengine_queue", 
    "name" : "rule_id_1" 
} 
] 

周りにどのような方法がありますこの?

+0

更新が得られないという警告です。何かが実際に動作を停止するか、警告だけを心配していますか? MongoDB/10genは、何がログに記録されるべきなのか、そうでないべきであるべきなのかについて、若干異なる意見を持っているので、かなりの数のものが警告としてログに記録されることになるでしょう。 –

+0

いいえ、すべてうまくいきます。私は警告を心配しています。私のセットアップが生産に持ち込まれたときに気になること(約50万通の書類) – clops

+0

比較的無邪気です。私は答えを投稿します –

答えて

4

興味のある人には、セットがソートされるキーで終わる別のインデックスを作成しなければなりませんでした。

+1

MongoDBのドキュメントでは、「ソート列は索引で最後に使用された列でなければなりません」と記載されています。 –

+0

(http://www.mongodb.org/display/DOCS/Indexing+Advice+and+FAQ#IndexingAdviceandFAQ-1.Thesortcolumnmustbethelastcolumnintheexex) @AlexanderAzarovそれはもはやこれを言うようです。 – bmargulies

+1

確かに。 「複合インデックスを使用するソートを含むクエリの場合、最初のソートされたフィールドの前にあるすべてのフィールドが一致することを確認してください」(http://docs.mongodb.org/manual/applications/indexes/#use -indexes-to-sort-query-results) –

1

このような警告は、何らかの理由で保持しているロックを解放できないため、生成する操作(長い更新、削除など)ができない場合にスローされます。

ソート対象のフィールドはインデックスに登録されていますか?インデックスを追加しないと、おそらく警告が削除されます。

+0

はい、上記の "getIndexes()"の結果からわかるように、フィールドはインデックスされています – clops

+0

ああ、ごめんなさい。その場合、あなたは私が思う警告で生きなければならないでしょう。繰り返しますが、結果を出すことはできますが、できない長い更新の結果だけです。ところで、そこには1つか2つの無駄なインデックスがあります。索引{a:1、b:1、c:1}と{a:1}は前者が後者を含むので有用ではないことに注意してください。 –

+0

私は複合インデックスを保持することをお勧めしますか? "C"または "B"と "C"だけを使用する可能性がある他の操作はどうでしょうか? – clops

関連する問題