[SERVER-13417] mongoperf can overstate performance problems in ext-X filesystems Created: 31/Mar/14 Updated: 15/Mar/16 Resolved: 15/Mar/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Performance |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Mark Callaghan | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
People who use mongoperf to compare XFS and ext-X might get results that overstate the benefits of XFS. The problem is a per-inode mutex that is locked during writes with buffered IO so there won't be pending writes from pending threads. The mutex contention isn't as bad for reads but from past experience still hurts concurrent IO performance. The workaround is to let mongoperf use multiple files. That would also make the mongoperf load more realistic given mongodb will use many files. This is one example – http://edgystuff.tumblr.com/post/81219256714/tips-to-check-and-improve-your-io-performance-for-high |
| Comments |
| Comment by Ian Whalen (Inactive) [ 15/Mar/16 ] |
|
Apologies for the delay in responding on this issue, but we've decided not to proceed with any further enhancements to mongoperf in its current form - as such we're closing this as Won't Fix. We aren't moving the existing code or removing the binary, but any changes going forward would almost certainly involve first moving the existing functionality to a newly written tool. We made a similar decision with our other tools in 3.0.0 and have been very happy with the results. We don't have a specific timeline for this work, but you can vote on and add yourself as a watcher to |
| Comment by Mark Callaghan [ 31/Mar/14 ] |
|
More context on this: |