GlusterFS Benchmark - Revision history

Tiziano: /* Simulating Qemu/Libvirt re-open */

2014-07-04T07:20:30Z

Simulating Qemu/Libvirt re-open

← Older revision		Revision as of 09:20, 4 July 2014
Line 66:		Line 66:
	* use a much smaller file such that the jobs can finish		* use a much smaller file such that the jobs can finish
	* every job is run after the previous finished (instead of in parallel)		* every job is run after the previous finished (instead of in parallel)

			So this should lead to a 4*N threads for fio instead of simply 4 in case the bug is still present.

	<source lang='bash'>		<source lang='bash'>

Tiziano at 15:56, 3 July 2014

2014-07-03T15:56:07Z

@@ Line 38: / Line 38: @@
 <source lang='bash'>
 fio --ioengine=gfapi \
      --volume=virtualization \
@@ Line 52: / Line 51: @@
      --iodepth=16 \
      --numjobs=16 \
      --runtime=60 \
      --group_reporting \
      --name=fio-test
 </source>

Tiziano at 15:28, 3 July 2014

2014-07-03T15:28:50Z

← Older revision		Revision as of 17:28, 3 July 2014
Line 4:		Line 4:

	The options for fio are mostly taken from http://www.storagereview.com/fio_flexible_i_o_tester_synthetic_benchmark		The options for fio are mostly taken from http://www.storagereview.com/fio_flexible_i_o_tester_synthetic_benchmark

			The numbers generated by the operations below should be compared to running fio directly on the bricks which will give you an idea on how much of the native speed is achieved.

	== FUSE mount ==		== FUSE mount ==

Tiziano: /* gfapi */

2014-07-03T15:27:13Z

gfapi

← Older revision		Revision as of 17:27, 3 July 2014
Line 32:		Line 32:

	== gfapi ==		== gfapi ==

			Using the same basic parameters we can use the gfapi backend of fio to simulate operation via gfapi.

	<source lang='bash'>		<source lang='bash'>

Tiziano: /* FUSE mount */

2014-07-03T15:18:32Z

FUSE mount

@@ Line 16: / Line 16: @@
 cd /var/virtualization
 fio --ioengine=libaio \
      --filename=fio.test \
      --size=256M \

Tiziano: Created page with "The following document gives some ideas on how to benchmark an installation with regard to the GlusterFS storage backend. For most of the benchmarks, the excellent [http://gi..."

2014-07-03T15:17:26Z

Created page with "The following document gives some ideas on how to benchmark an installation with regard to the GlusterFS storage backend. For most of the benchmarks, the excellent [http://gi..."

New page

The following document gives some ideas on how to benchmark an installation with regard to the GlusterFS storage backend.

For most of the benchmarks, the excellent [http://git.kernel.dk/?p=fio.git;a=summary fio] tool will be used. At least version 2.1.11 of fio is required for gfapi (and O_DIRECT) support.

The options for fio are mostly taken from http://www.storagereview.com/fio_flexible_i_o_tester_synthetic_benchmark

== FUSE mount ==

The following commandline creates a file <code>fio.test</code> with the size of 256MB, opened using O_DIRECT and simulates a random read/write load where 70% are read operations.

The options <code>refill_buffers</code> are supposed to make the workload more realistic in the presence of a storage backend (filesystem and below) doing de-duplication.

The test will run for 1 minute with 16 processes in parallel doing the same thing and the reporting is done for the whole group of processes.

<source lang='bash'>
cd /var/virtualization
fio --ioengine=libaio \
--filename=fio.test \
--size=256M \
--direct=1 \
--rw=randrw \
--refill_buffers \
--norandommap \
--bs=8k \
--rwmixread=70 \
--iodepth=16 \
--numjobs=16 \
--runtime=60 \
--group_reporting \
--name=fio-test
</source>