Seeing ClientCursor::staticYield after upgrade to 2.6

[Andreas Gerauer]

Hi,

after the upgrade from 2.4.10 to 2.6.1 a lot of the following log entries started to appear;

[conn599] ClientCursor::staticYield can't unlock b/c of recursive lock ns:  top: { opid: 1215952, active: true, secs_running: 0, op: "query", ns: "xxx.yyyy", query: { findandmodify: "yyyy", query: { ... }, update: { $set: {... } }, upsert: true, new: true, fields: { ... } }, client: "x.x.x.x:50476", desc: "conn599", threadId: "0x7f6480539700", connectionId: 599, locks: { ^: "w", ^xxx: "W" }, waitingForLock: false, numYields: 0, lockStats: { timeLockedMicros: {}, timeAcquiringMicros: { r: 0, w: 4 } } }

What does it mean?

Thanks

Andreas

[Asya Kamsky]

Andreas,

Sorry, not sure how this got missed before, but FYI, the "ClientCursor::staticYield" message basically means that you are doing a findAndModify using a query that's not efficient to perform an update.

So why did the query used to be efficient in 2.4.10 but become inefficient in 2.6.x?   The query and index picking code is very different in 2.6 and we've seen a number of cases where less-than-optimal index gets picked.

It seems to happen more often to folks who have a lot of indexes, especially redundant ones.  Also some bugs  were fixed in 2.6.2 and 2.6.4 so if you check and make sure you don't have any unnecessary indexes and update to 2.6.4 - see if that fixes the problem.  

Also, make sure you actually need findAndModify - if you don't need the document being updated returned to the application you should use "update" instead of "findAndModify".

Asya

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.

To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/d504014c-e984-40bb-8046-0c73c6ac0a8e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Andreas Gerauer]

Hi Asya,

thanks for your reply. We started to ignore the messages, because there seemed to be no impact on data integrity and performance was satisfactory. Still I'm interested in a solution and to learn something for the future :)

The collection in question is part of a write heavy database. In peak times it receives a hundreds of findAndModify queries per second. It's sibling collections only receive updates (but in bigger quantities). The collection has a two indices: a unique index on three fields and the usual _id index. The findAndModify query specifies exactly the three indexed fields. I'm interested in updating the record and getting the _id field out of it. Would it be more efficient for MongoDB to do an update followed by a find when possible?

Thanks for your help

Andreas

[Asya Kamsky]

Andreas:

If you want to get the _id of the document that was modified, then
findAndModify is better than update followed by a find - what I would
check would be that the index you expect is being used for the update.
Take the part from the findAndModify log like inside "query" and run
it in the shell with explain:

> db.collection.find({query-here}).explain()

and see if it shows that unique index being used - if so, and if the
performance is up to your expectations, then you're fine. However,
if the index isn't being used as expected, then you might look at how
you can make the query part of the update/findAndModify more
performant.

Asya

> https://groups.google.com/d/msgid/mongodb-user/268c484f-953f-4aba-9f0d-2fe8cdc62c38%40googlegroups.com.