From c59e0b14d4f0d65ce5ee84b954a23c4e70455eb3 Mon Sep 17 00:00:00 2001 From: karthiksundaravel Date: Fri, 8 May 2020 14:16:05 +0530 Subject: [PATCH 1/2] Fix the sample job file and execution commands --- agent/bench-scripts/pbench-fio.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/agent/bench-scripts/pbench-fio.md b/agent/bench-scripts/pbench-fio.md index a70ca9ed0b..b3c6f345e8 100644 --- a/agent/bench-scripts/pbench-fio.md +++ b/agent/bench-scripts/pbench-fio.md @@ -200,21 +200,21 @@ Then you construct a fio job file for your initial sequential tests, and this wi [global] # size of each FIO file (in MB) - size=$@ + size=1GiB # do not use gettimeofday, much too expensive for KVM guests clocksource=clock_gettime # give fio workers some time to get launched on remote hosts startdelay=5 # files accessed by fio are in this directory - directory=$@ + directory=/mnt/fio/files # write fio latency logs in /var/tmp with "fio" prefix - write_lat_log=/var/tmp/fio + write_lat_log=fio # write a record to latency log once per second log_avg_msec=1000 # write fio histogram logs in /var/tmp/ with "fio" prefix - write_hist_log=/var/tmp/fio + #write_hist_log=/var/tmp/fio # write histogram record once every 10 seconds - log_hist_msec=10 + #log_hist_msec=10 # only one process per host numjobs=1 # do an fsync on file before closing it (has no effect for reads) @@ -233,9 +233,9 @@ Then you construct a fio job file for your initial sequential tests, and this wi And you write it to a file named fio-sequential.job, then run it with a command like this one, which launches fio on 1K guests with json output format. - /usr/local/bin/fio --client-file=vms.list --pre-iteration-script=drop-cache.sh \ - --rw=write,read -b 4,128,1024 -d /mnt/fio/files --max-jobs=1024 \ - --output-format=json fio-sequential.job + pbench-fio --client-file=vms.list --pre-iteration-script=drop-cache.sh \ + -t write,read -b 4,128,1024 -d /mnt/fio/files --numjobs=32 \ + --job-file fio-sequential.job This will write the files in parallel to the mount point. The sequential read test that follows can use the same job file. The **--max-jobs** parameter should match the count of the number of records in the vms.list file (FIXME: is --max-jobs still needed?). From 3608585f9f2b869b7eb01d3e1fa29d37c4bff95a Mon Sep 17 00:00:00 2001 From: karthiksundaravel Date: Sat, 9 May 2020 09:23:59 +0530 Subject: [PATCH 2/2] Fix example of OpenStack Cinder volumes The sample job file and the fio / pbench-fio commands needs change in order to be usable. The parameters size, directory were not automatically filled for the commands given. The path for write_lat_log shall not include '/var/tmp/' similar to https://github.com/distributed-system-analysis/pbench/blob/master/agent/bench-scripts/templates/fio.job --- agent/bench-scripts/pbench-fio.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/agent/bench-scripts/pbench-fio.md b/agent/bench-scripts/pbench-fio.md index b3c6f345e8..ff986712ce 100644 --- a/agent/bench-scripts/pbench-fio.md +++ b/agent/bench-scripts/pbench-fio.md @@ -199,7 +199,8 @@ Now format the filesystems for each cinder volume and mount them: Then you construct a fio job file for your initial sequential tests, and this will also create the files for the subsequent tests. certain parameters have to be specified with the string `$@` because pbench-fio wants to fill them in. It might look something like this: [global] - # size of each FIO file (in MB) + # size of each FIO file (in MB). + # size = ( size of /dev/vdb ) / numjobs size=1GiB # do not use gettimeofday, much too expensive for KVM guests clocksource=clock_gettime @@ -207,14 +208,14 @@ Then you construct a fio job file for your initial sequential tests, and this wi startdelay=5 # files accessed by fio are in this directory directory=/mnt/fio/files - # write fio latency logs in /var/tmp with "fio" prefix + # write fio latency logs write_lat_log=fio # write a record to latency log once per second log_avg_msec=1000 # write fio histogram logs in /var/tmp/ with "fio" prefix - #write_hist_log=/var/tmp/fio + write_hist_log=/var/tmp/fio # write histogram record once every 10 seconds - #log_hist_msec=10 + log_hist_msec=10 # only one process per host numjobs=1 # do an fsync on file before closing it (has no effect for reads) @@ -231,13 +232,13 @@ Then you construct a fio job file for your initial sequential tests, and this wi # do not create just one file at a time create_serialize=0 -And you write it to a file named fio-sequential.job, then run it with a command like this one, which launches fio on 1K guests with json output format. +And you write it to a file named fio-sequential.job, then run it with a command like this one, which launches 4 fio jobs on each guests with json output format. pbench-fio --client-file=vms.list --pre-iteration-script=drop-cache.sh \ - -t write,read -b 4,128,1024 -d /mnt/fio/files --numjobs=32 \ + -t write,read -b 4,128,1024 -d /mnt/fio/files --numjobs=4 \ --job-file fio-sequential.job -This will write the files in parallel to the mount point. The sequential read test that follows can use the same job file. The **--max-jobs** parameter should match the count of the number of records in the vms.list file (FIXME: is --max-jobs still needed?). +This will write the files in parallel to the mount point. The sequential read test that follows can use the same job file. Since we are using buffered I/O, we can usually get away with using a small transfer size, since the kernel will do prefetching, but there are exceptions, and you may need to vary the **bs** parameter.