[SERVER-18907] mongoperf behavior is confusing Created: 05/May/15  Updated: 17/Sep/15  Resolved: 16/Jun/15

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Question Priority: Major - P3
Reporter: Yuri Finkelstein Assignee: David Daly
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux, ext4


Issue Links:
Related
related to SERVER-20426 mongoperf is producing questionable r... Closed
Backwards Compatibility: Fully Compatible
Sprint: CAP - 3.1.5
Participants:

 Description   

In non-mmf mode monoperf deletes a file with constant non-configurable name mongoperf_testfile_tmp, creates it again, and then in each thread performs random 4k write followed by fdatasync.

On ext4 fdatasync caused inode mutex to be taken. So, whether I give mongoperf 1 thread or many because of this mutex I always get the same throughput.
It took me a while to figure out why this was the case. I think users should be warned about this.

Another issue is that the natural solution to this is to launch N 1-threaded instances of this program. But because the file name is not customizable they end up writing to the same file. But there is yet another catch. Because each instance first deletes the file and creates it again the there will be 64 different inodes created for the same file name and only one is real. Nonetheless the effect of this mess is that 64 instances can freely write to different files and collectively reach much large IO throughput.
All of this is extremely confusing.

The utility needs to expose file name via config parameter so that the user can make intelligent choices of that name in each instance. Also, deleting the file in the beginning even if it exists - I would expose another option to control that.



 Comments   
Comment by David Daly [ 16/Jun/15 ]

Hi yfinkelstein. Thanks for raising this issue. Mongoperf disk utility is not
heavily used internally. There are a number of general purpose storage
benchmarking tools and those are probably better choices for IO
benchmarking your system. Two such open source tools are fio and
iozone.

Fio stands for flexible io tester, and is meant to benchmark the
hardware. Fio has support for random or squential, read or write
access, and combinations of those. There is a HowTo document included
in the fio source. Additionally
the fio package is included in most linux distribution package
managers. There is are multiple tutorials on benchmarking with fio,
with some short examples. Here are two:

IOZone is a filesystem benchmarking tool.
And here are some examples for IOZone: http://www.thegeekstuff.com/2011/05/iozone-examples/

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