suggestion: patch to make per-thread IOPS more accurate
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines
The following small patch to
stat.c(using fio 2.2.4 from github) outputs IOPS field in JSON format as a floating point number instead of an integer. This improves accuracy in case where fio --client runs use lots of threads with single-digit IOPS per thread. It seems to work, here's a snippet of output from a short fio run with rate_iops=10 in the job file.
Quoted 5 lines
"write" : {
"io_bytes" : 6464,
"bw" : 646,
"iops" : 10.10,
"runtime" : 10000,Thanks for this. I have applied the patch, and it works fine for me. Very useful when testing with many fio jobs on slower storage.
Quoted 48 lines
Why the patch: IOPS number is rounded to integer in
stats.ccalls tonum2str(). This doesn't sound like much of a problem because in many use cases, with large IOPS number the error is negligible. But in this use case where we have many threads (we would like to get into the thousands eventually), the IOPS/thread may be quite low and integer rounding can introduce significant error. For example, if we are doing 5,000 IOPS over 1,000 threads, average throughput is 5 IOPS and potential error is ~20%, but some threads could have much higher error in IOPS because of integer format.background: fio's --client option could prove *extremely* useful for work where we inject I/O workload from tens, hundreds or even thousands of VMs to an OpenStack, container or other virtualization environment. I really like this feature combined with "fio --server --daemonize=/var/run/fio-svr.pid" command run on workload generators, because it means that we don't have to use ssh/pdsh to start up a connection and launch the workload generator on each host. ssh is problematic for this, I have to throttle it because it locks up if you have too many concurrent ssh sessions starting up. pdsh is better but still has limits because you actually have to start each thread up from scratch, sometimes in competition with the workload you want to measure.
stat.c renamed from stat.c.sav +4
-3@@ -674,7 +674,8 @@ struct group_run_stats *rs, int ddir, struct json_object *parent) { unsigned long min, max; -unsigned long long bw, iops; +unsigned long long bw; +double iops;unsigned int *ovals =NULL ;double mean, dev;unsigned int len, minv, maxv;@@ -698,12 +699,12 @@uint64_t runt = ts->runtime[ddir]; bw = ((1000 * ts->io_bytes[ddir]) / runt) /1024 ; - iops = (1000 * (uint64_t ) ts->total_io_u[ddir]) / runt; + iops = (1000.0 * (uint64_t ) ts->total_io_u[ddir]) / runt; }json_object_add_value_int (dir_object,"io_bytes" , ts->io_bytes[ddir] >>10 );json_object_add_value_int (dir_object,"bw" , bw); -json_object_add_value_int (dir_object,"iops" , iops); +json_object_add_value_float (dir_object,"iops" , iops);json_object_add_value_int (dir_object,"runtime" , ts->runtime[ddir]);json_object_add_value_int (dir_object,"total_ios" , ts->total_io_u[ddir]);
Quoted 1 line
json_object_add_value_int(dir_object, "short_ios", ts->short_io_u[ddir]);
-Andrew