MongoSF: MongoDB Concurrency Internals in v2.2

MongoSF: MongoDB Concurrency Internals in v2.2






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

MongoSF: MongoDB Concurrency Internals in v2.2 MongoSF: MongoDB Concurrency Internals in v2.2 Presentation Transcript

  • Concurrency Internals in v2.2 Dwight Merriman, CEO & Co-Founder, 10gen This session begins at 2:45PM...#mongosf
  • Version #svA.B.C Even B’s are stable Odd B’s are dev branch.Current stable = 2.0.x (e.g. v2.0.4)Current dev branch = 2.1.x (e.g. v2.1.1) (not for production) Once blessed, 2.1.x becomes v2.2.0Thus 1.6 -> 1.8 1.8 -> 2.0 2.0 -> 2.2 2.2 -> 2.4 are similar magnitudes of change
  • Two big changes in 2.21. Eliminate the global reader/writer lock “Granularization” First step is db-level locks.2. PageFaultException architecture (yield lock on a page fault)
  • Lock per db• Reader/writer lock per database – First step towards more granularity• Global lock is still possible but now very rare (e.g. journaling locks the world for short intervals; the journal is shared by all dbs)• More granularity should be fairly easy to add in the future – hard part is done – Were places in code where assumptions were made about exclusivity when in a write lock; those are gone now
  • Lock per db• In v2.1.1+ sometimes two db’s are locked by the same thread – admin db for security info lookup – local db for replication (writing to the oplog)
  • Structure of a write operationLock(mydb);Do_write_operation(mydb); // slowLock(local_database);Write_to_replication_oplog(); // fastUnlock(local_database);Unlock(mydb);
  • Lock status can be inspected• currentOp()• serverStatus()• MMS monitoring will evolve too to help with instrumentation of system status in this regard
  • PageFaultException• Improves concurrency within a single collection
  • PageFaultException
  • PageFaultException• If on a write operation – Mutation has yet to occur – And we are going to page fault• Then – Throw PageFaultException – While unlocked, touch the page – Retry the operation
  • The Future• More granularity• Now that there is some, much easier• Collection level for sure• Document level locking (latching) – there are some nuances (btrees) – but at least directionally, yes
  • Thanks Please help us test the upcoming v2.2 release by hammering the dev branch releases in your QA environment (i.e., v2.1.1).Next :