[SERVER-7346] Performance regression in v2.2: write lock upgrading Created: 13/Oct/12 Updated: 11/Jul/16 Resolved: 13/Feb/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Performance |
| Affects Version/s: | 2.2.0 |
| Fix Version/s: | 2.4.0-rc1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ben Becker | Assignee: | Mathias Stearn |
| Resolution: | Done | Votes: | 3 |
| Labels: | performance | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Mac OS X |
||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Description |
|
This is a case of significant reduction in performance when under heavy write load. The attached Java test client (MongoBenchTest.java) starts with 1 thread and ramps up to 10 threads, each inserting into a unique db with safe wc. Basically, once the durability thread has trouble keeping up, we start seeing commitIfNeeded upgrade the db lock from shared to exclusive write, and with 10 threads, the overall insert rate drops by ~50% compared to 1 thread. Disabling journaling results in much faster results, but it's just a tad faster than v2.0.7 with journaling enabled. v2.0.7 w/o journaling is the fastest. |
| Comments |
| Comment by Mathias Stearn [ 13/Feb/13 ] |
|
Just tested on windows with 2.2.3, 2.0.8 and 2.4.0-rc1, and all latencies are the same. thomasr Please open a separate ticket for your issue. It doesn't seem related. |