-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Peformance plateaus while performance testing on more than 3 drives with multiple jobs per each drive #703
Comments
Hmm I fairly sure fio doesn't share very much at all when jobs are forked off but I wonder if having them all come from the same parent influences how they are scheduled... Could you use one of the cpu options (e.g. https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-cpus-allowed-policy ) that forcefully spreads them out? |
Quick summary:
You appear to have plenty of cpu left so I'm a bit baffled. The only thing I wonder about is whether Line 1122 in f1867a7
However, as this isn't so much an issue in fio and more of a "How do I/Why is?" question it is better aimed at the fio mailing list (note that the list only accepts plain text emails)... Could you move this question there? |
It's worth nothing that posixaio is usually a horrible choice, in particular so for iodepth=1. This is because the underlying libc implementation is a thread pool, and not a very good one at that. Nobody should be using posixaio on Linux... |
Setting to needinfo pending a reply from @rustyscottweber ... |
Closing because we need more information from the reporter to take this further. @rustyscottweber - please re-open this issue if/when you're able to supply the requested information requested in #703 (comment) . Thank you! |
As the title would suggest, attempting to formulate a single job file to conduct performance on multiple drives at the same time results in a performance plateau after the third drive added and does not scale correctly to the expected performance of the drives being used. This result is the same regardless of wither or not the threading or process model is used. However, splitting the fio job file into multiple processes where each drive gets it's own process spawned from the command line, the results will scale correctly. For now, we have been able to work around the issue by doing just this. Is there some type of global lock on each process that might be creating a bottle neck perhaps?
Example job attached.
ExampleFiles.zip
The text was updated successfully, but these errors were encountered: