[SERVER-17495] Stand alone mongod throughout dropped by 40% after 17 hours of insert only workload Created: 06/Mar/15 Updated: 19/Jan/17 Resolved: 19/Jan/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage, WiredTiger |
| Affects Version/s: | 3.0.0-rc11, 3.1.6 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Eitan Klein | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Incomplete | Votes: | 1 |
| Labels: | 28qa | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Operating System: | Windows | ||||||||||||||||||||||||
| Sprint: | Platform 4 06/05/15, Platform 5 06/26/16, Platform 6 07/17/15, Platform 7 08/10/15 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
Version – Environment: • Single mongod with wiredtiger as storage engine Workload: • Used hammer.mongo to do insert only workload Will continue and investigate this issue At this stage
Next plan – Keep it running to death and debug it when the throughput is significant low. |
| Comments |
| Comment by Ramon Fernandez Marina [ 19/Jan/17 ] |
|
The symptoms in this ticket are very similar to known cache eviction related issues in WiredTiger that we've been addressing in MongoDB 3.2 and 3.4. Since the testing in this ticket was conducted MondoDB has released three major versions and numerous patch releases, so I believe that the best way forward is to resolve this ticket now – users running into similar behaviors are welcome to create new tickets, and the diagnostic data collection feature introduced in MongoDB should help us determine if there are still bugs around this area of the product. Thanks, |
| Comment by Alessandro Gherardi [ 19/Jan/17 ] |
|
Was this issue fixed in 3.4.1? If not, what's the target release. Thanks. |
| Comment by Nick Judson [ 21/Sep/16 ] |
|
Last I heard it might be fixed in 3.4, although I haven't checked. |
| Comment by Alessandro Gherardi [ 21/Sep/16 ] |
|
It looks like all related tickets have been closed or resolved. I guess that means that memory management on Windows has been straightened out. So can this issue be closed? It's been open for 1 year and a half. |
| Comment by Nick Judson [ 18/Dec/15 ] |
|
It's a lot better. I'm guessing it will be fixed once the memory management on Windows is straightened out. |
| Comment by Alessandro Gherardi [ 18/Dec/15 ] |
|
Is this still an issue in 3.2.0/3.2.1? |
| Comment by Eitan Klein [ 18/Aug/15 ] |
|
adding CPU profiler output |
| Comment by Eitan Klein [ 18/Aug/15 ] |
|
add missing title top for left graph |
| Comment by Eitan Klein [ 18/Aug/15 ] |
|
This issue also observed with db version v3.1.7-pre- Environment: Same setup, machine EC2 I2 machine (running w/o the known windows timer issues On this case, it's appear that increase in latency over time (see client view on this issue) is responsible for the performance drop, latency started to raise after 8 hours of execution. I will attached profiler |
| Comment by Michael Cahill (Inactive) [ 26/Jun/15 ] |
|
eitan.klein, fixes are being tracked in |
| Comment by Eitan Klein [ 25/Jun/15 ] |
|
michael.cahill I initially thought this is not a release blocker but the most recent results seems that performance dropped in min see compression (we looks worse then 3.0.0 from this prescriptive) |
| Comment by Eitan Klein [ 24/Jun/15 ] |
|
michael.cahill See data point from today, related to this issue. acm should have the next steps. |
| Comment by Eitan Klein [ 21/Apr/15 ] |
|
The windows heap contention duplicated over many different tickets, I'm closing this one a duplicate of others that become the primary Will re-open if this issue will repro after the fix |
| Comment by Nick Judson [ 16/Mar/15 ] |
|
Possible dup: |