[SERVER-16951] Restrict maximum number of in-flight operations Created: 20/Jan/15 Updated: 18/Sep/15 Resolved: 28/Jan/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.0.0-rc7 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Andy Schwerin | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Participants: | |||||||||
| Description |
|
With document-locking storage engines, and even with collection-level locking in MMapV1, the number of lock-holding write operations is no longer bound by the number of databases in the system. This increases the likelihood of a concurrency explosion, where potentially hundreds or thousands of operations are admitted to the storage subsystem simultaneously, and forward progress ends up being limited by scheduling overhead, write conflicts, etc. We could constrain this behavior by restricting the number of non-administrative operations allowed to hold the global lock simultaneously. Then, every initial lock acquisition and yield recovery would become an opportunity to constrain forward progress for writes, reads or both. |
| Comments |
| Comment by Githook User [ 29/Jan/15 ] |
|
Author: {u'username': u'igorcanadi', u'name': u'Igor Canadi', u'email': u'icanadi@fb.com'}Message: Signed-off-by: Benety Goh <benety@mongodb.com> |
| Comment by Githook User [ 29/Jan/15 ] |
|
Author: {u'username': u'igorcanadi', u'name': u'Igor Canadi', u'email': u'icanadi@fb.com'}Message: Signed-off-by: Benety Goh <benety@mongodb.com> |
| Comment by Githook User [ 28/Jan/15 ] |
|
Author: {u'username': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}Message: (cherry picked from commit bbd95ca6a8b538b4cffece0b9d9c3ed811a455a7) |
| Comment by Githook User [ 28/Jan/15 ] |
|
Author: {u'username': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}Message: (cherry picked from commit 8299d7435855820d16b25f4a66b572ddf6a11cf5) |
| Comment by Githook User [ 28/Jan/15 ] |
|
Author: {u'username': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}Message: |
| Comment by Githook User [ 28/Jan/15 ] |
|
Author: {u'username': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}Message: |
| Comment by Andy Schwerin [ 23/Jan/15 ] |
|
Early experiments suggested this wasn't helping any of our current problems. We can reintroduce the concept the next time we reexamine thread scheduling holistically. |