0

I am using Mongo 2.6 and the Reactive Mongo driver running on Ubuntu Linux.

I have a process which does the following: Read a record, augment the record, then update the record. Due to various constraints that operation can not be made more atomic. Records are somewhat large (100kb-900kb).

I am trying to understand the locking behavior in this situation because I am seeing a few things that seem odd. This includes the presence of what appears to be global locks and the fact that sharding does not seem to improve throughput at all.

When running this process on multiple threads (10 threads total), I observe the following:

  • Database locks average around 35%
  • Queued Reads average around 450
  • Queued Writes are usually 0 occasionally going to 1
  • Active Reads are usually 0
  • Active Writes vary from 0 to 10 but tend to 0 more often.
  • Current Operations show a number of Update operations with a Write lock on "^". These operations never seem to be waiting for a lock.
  • Current Operations show a number of Update operations with a Write lock on "^MyDatabase". These operations are often waiting for a lock.
  • Current Operations show a number of Query operations with a lock Write lock on "^MyDatabase". These operations are often waiting for a lock.

Q: Would the write operations with the global write lock ("^") prevent reads from occurring? What causes these locks to occur?

EDIT:

Here are some examples of some of the operations I see when I do db.currentOp()

The one I am most concerned about is this:

{
    "opid" : 83740,
    "active" : true,
    "secs_running" : 0,
    "microsecs_running" : NumberLong(971125),
    "op" : "update",
    "ns" : "my_database.my_collection_1",
    "query" : {
            "key" : "395b0a88-ccfb-441f-9c98-627b1f772f21",
            "index" : "1000"
    },
    "client" : "xx.xx.xx.xx:123456",
    "desc" : "conn49",
    "threadId" : "0x7fa1c79a2700",
    "connectionId" : 49,
    "locks" : {
            "^" : "w"
    },
    "waitingForLock" : false,
    "numYields" : 0,
    "lockStats" : {
            "timeLockedMicros" : {
                    "r" : NumberLong(0),
                    "w" : NumberLong(336)
            },
            "timeAcquiringMicros" : {
                    "r" : NumberLong(0),
                    "w" : NumberLong(3)
            }
    }
}

However I see others like the following:

{
    "opid" : 1340,
    "active" : false,
    "op" : "update",
    "ns" : "",
    "query" : {
            "key" : "f7e0ce90-0d0e-4094-9a27-b4fc88ca3171"
    },
    "client" : "xx.xx.xx.xx:123456",
    "desc" : "conn41",
    "threadId" : "0x7fa1c81aa700",
    "connectionId" : 41,
    "locks" : {
            "^" : "w",
            "^my_database" : "W"
    },
    "waitingForLock" : true,
    "numYields" : 0,
    "lockStats" : {
            "timeLockedMicros" : {

            },
            "timeAcquiringMicros" : {

            }
    }
},
{
    "opid" : 78506,
    "active" : true,
    "secs_running" : 0,
    "microsecs_running" : NumberLong(3362),
    "op" : "query",
    "ns" : "my_database.my_collection_2",
    "query" : {
            "key" : "2b5c59fa-b649-4c73-91ff-582c21a919ed"
    },
    "client" : "xx.xx.xx.xx:123456",
    "desc" : "conn49",
    "threadId" : "0x7fa1c79a2700",
    "connectionId" : 49,
    "locks" : {
            "^" : "r",
            "^my_database" : "R"
    },
    "waitingForLock" : false,
    "numYields" : 5,
    "lockStats" : {
            "timeLockedMicros" : {
                    "r" : NumberLong(1889),
                    "w" : NumberLong(0)
            },
            "timeAcquiringMicros" : {
                    "r" : NumberLong(830),
                    "w" : NumberLong(0)
            }
    }
}
Wade
  • 346
  • 2
  • 12
  • It's hard to say much without more information, but certainly a global writer lock blocks readers. MongoDB users a readers-writer lock. There's a great general explanation of how the locking works in this [old SO post](http://stackoverflow.com/questions/17456671/to-what-level-does-mongodb-lock-on-writes-or-what-does-it-mean-by-per-connec) – wdberkeley Aug 27 '14 at 16:15
  • What kind of additional information would be helpful? I am more than happy to provide. Really what I need to know is why would a global lock even be occurring? This is a simple update on a document (granted a somewhat large document). Shouldn't it only be doing DB level locks? – Wade Aug 27 '14 at 16:25
  • What does ^ mean? How do you know it's global lock? I haven't seen that before. The `locked db` field from mongostat should show you a specific database lock % combined with the global lock %. – wdberkeley Aug 27 '14 at 16:51
  • http://docs.mongodb.org/manual/reference/method/db.currentOp/ This link gives a description of the locks, including the fact that "^" apparently represents a global lock. – Wade Aug 28 '14 at 15:50
  • Ah, my bad. Thought you were talking about mongostat...though it's pretty obvious you weren't. Will take another look at this soon. – wdberkeley Aug 28 '14 at 15:51
  • Could you give some sample output from `db.currentOp`? Normal write operations like updates don't take global locks, so I want to see exactly what these global lock operations are. – wdberkeley Aug 28 '14 at 17:50
  • See edits above. Examples from db.currentOp included. – Wade Aug 28 '14 at 22:15

0 Answers0