[Linux-cluster] stress-testing GFS ?

Boris Ostrovsky baostr at gmail.com
Thu Mar 16 18:39:17 UTC 2006


I have recently ran some very simple iozone tests on GFS (and OCFS2) and got
somewhat disappointing results. I am attaching the spreadsheet.

The first test was to measure single-node performance with ext3, GFS and
OCFS2 partition that I mounted in a single node. The second was to use two
nodes and run iozone in parallel (by hand, i.e. without -m/-t options).

Single node performances were comparable in terms of wallclock time,
although the benchmark values for ext3 were clearly better (so I am not sure
I understand why wallclock times are so close). 2-node numbers show
substantial performance degradation.

Note, I didn't do any tuning, mostly because I didn't find much
documentation on the subject (except that for OCFS2 I set cluster size to
1MB, which helped). The nodes were running FC4 with the disk connected to
nodes via Emulex HBA. and cluster tools 1.01

I'd be very interested to hear comments on the numbers and hopefully some
tuning suggestions.


Thanks.
-boris


Date: Wed, 15 Mar 2006 14:20:28 -0800
> From: Michael Will <mwill at penguincomputing.com>
> Subject: Re: [Linux-cluster] stress-testing GFS ?
> To: linux clustering <linux-cluster at redhat.com>
> Message-ID: <4418932C.9080001 at jellyfish.highlyscyld.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> iozone does test for a lot of different access patterns, and can create
> nice spreadsheets including graphs
> from the point of view of a single node. It also has a multiple node
> flag for running it across a cluster. See -+m and -t
> options. It knows how to use 'rsh' and can also be configured for any
> other remote execution command by setting the
> enviroment variable RSH to say ssh or bpsh.
>
> Don't forget to post your benchmark results to this mailinglist ;-)
>
> Michael
>
> Birger Wathne wrote:
>
> > I would like to put my cluster through a little controlled hell before
> > declaring it ready for production.
> >
> > Is there any kind of stress-test/verification procedure to 'certify'
> > shared storage with GFS?
> > Ideally there would be some distributed software that could be run in
> > a cluster to check that the shared storage behaves as expected under
> > all kinds of load. Throughput, concurrent writing, GFS locking, file
> > system locking, etc...
> > Something that could interface with GFS internals to see that
> > everything was 'right' at every step.
> >
> > Since I have seen nothing about the issue, I assume something like
> > that doesn't exist, so... Any ideas on how to stress test GFS?
> > Homegrown scripts? Known problems with hardware that a test should
> > look for?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20060316/d61c1e86/attachment.htm>
-------------- next part --------------
						random	random	bkwd	record	stride
		write	rewrite	read	reread	read	write	read	rewrite	read	fwrite	frewrite	fread	freread


ext3		12.5min	113718	8335	91962	186143	4345	515	9612	258904	6002	112859	7230	76225	139576
gfs		13.5min	27217	8337	50117	62312	1611	604	8233	81180	5749	33633	7958	53301	40331
ocfs2		14.5min	42102	9345	65887	92481	1210	566	8136	155370	5605	41571	8699	78925	71724

gfs(n1)		46min	21467	5159	29705	35512	348	172	808	81188	4970	32680	8039	35667	58961
gfs(n2)		48min	40046	3493	29565	25093	504	327	906	81390	456	30035	4085	24953	22493

ocfs2 (n1)	38min	26813	4375	27406	27408	367	251	892	156194	5038	49998	8882	80288	111914
ocfs2 (n2)	35.5min	22756	5330	36728	29607	673	400	907	153949	953	45964	5117	34055	40158


More information about the Linux-cluster mailing list