MongoSF: MongoDB Concurrency Internals in v2.2
Download as pptx, pdf0 likes1,151 views
This document discusses concurrency changes in MongoDB version 2.2. It notes that version 2.2 will eliminate the global reader/writer lock and instead implement database-level locks for increased granularity. It also describes a new PageFaultException architecture that is designed to improve concurrency within a single collection by yielding locks when a page fault occurs. More granular locking at the collection and potentially document level is envisioned for the future.
MongoSF: MongoDB Concurrency Internals in v2.2
- 1. Concurrency Internals in v2.2 Dwight Merriman, CEO & Co-Founder, 10gen This session begins at 2:45PM... #mongosf
- 2. Version #s vA.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.0 Thus 1.6 -> 1.8 1.8 -> 2.0 2.0 -> 2.2 2.2 -> 2.4 are similar magnitudes of change
- 3. Two big changes in 2.2 1. Eliminate the global reader/writer lock “Granularization” First step is db-level locks. 2. PageFaultException architecture (yield lock on a page fault)
- 4. 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
- 5. 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)
- 6. Structure of a write operation Lock(mydb); Do_write_operation(mydb); // slow Lock(local_database); Write_to_replication_oplog(); // fast Unlock(local_database); Unlock(mydb);
- 7. Lock status can be inspected • currentOp() • serverStatus() • MMS monitoring will evolve too to help with instrumentation of system status in this regard
- 8. PageFaultException • Improves concurrency within a single collection
- 9. PageFaultException http://blog.pythonisito.com/2011/12/mongodbs-write-lock.html
- 10. 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
- 11. 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
- 12. 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 :