[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 TOOLS-1103 to be informed of updates as we weigh its priority against other projects that our Tools team are working on.

Comment by Mark Callaghan [ 31/Mar/14 ]

More context on this:
https://www.facebook.com/notes/mysql-at-facebook/xfs-ext-and-per-inode-mutexes/10150210901610933

Generated at Thu Feb 08 03:31:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.