Your SlideShare is downloading. ×
0

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

MongoSF: MongoDB Concurrency Internals in v2.2

1,355

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,355
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Concurrency Internals in v2.2 Dwight Merriman, CEO & Co-Founder, 10gen This session begins at 2:45PM...#mongosf
  • 2. 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
  • 3. 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)
  • 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 operationLock(mydb);Do_write_operation(mydb); // slowLock(local_database);Write_to_replication_oplog(); // fastUnlock(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 :

×