Hi, On Wed, 2011-03-23 at 01:34 -0400, Valeriu Mutu wrote: > Hi Steve, > > Thanks for the reply. > > On Mon, Mar 21, 2011 at 11:11:31AM +0000, Steven Whitehouse wrote: > > > Note that I've used the same setup for the GFS2 and ext3 tests: same machine, same networking config, same storage array (which is not used by anything else). > > > I also confirmed using "pingpong" [2] that I get a rate of about 4K locks/sec on this particular node against GFS2. > > > > > The pingpong test does not test metadata performance. > > I didn't say pingpong tests/measures metadata performance. I know it measures the _lock rate_, but wasn't sure how the lock rate impacts the metadata performance if any. > Generally not at all, since the fcntl locks use a totally different system to the locks which are used by the filesystem internally. > > There are a number of variables which you don't mention, but which are > > important for the test results. Firstly, what kind of storage are you > > using? > > I used an idle iSCSI Equallogic PS6500 storage array (48 disks, SATA, 7.2K RPM, 1TB each). It is configured as RAID-50. It is connected to the SAN switch via 4 1gigE links. By idle I mean it was not being used by anything at that time. Also, the VM (on which the test were run) is connected to the SAN switch via a single 1gigE link. MTU was set to 1500bytes due to problems with a 9000bytes MTU. > > > Secondly, was this lock_dlm or lock_nolock? > I've explicitly specified "lock_dlm" as the locking protocol when I created the shared GFS2 filesystem: > > > Also was there any memory pressure while the tests were running? > This VM is mostly idle, i.e. there's almost nothing running on it. It has 2Gb of RAM configured. > Ok. Should not be an issue then. > >Was noatime set on the filesystem (or indeed, other mount options)? > "noatime" was not set. This is how it's mounted: > /dev/mapper/Gfs2BenchmarksVG-gfs2benchLV on /gfs2bench type gfs2 (rw,hostdata=jid=0:id=196609:first=1) > I would highly recommend using noatime and nodiratime unless you have a good reason not to. That usually improves performance a fair amount. > You've mentioned that you are using other tools to measure the metadata performance of a given filesystem. What tools are those? Also, what numbers have you seen in your benchmarks when it comes to GFS2's metadata performance? > > Best, postmark, iozone, bonnie++, fsx, specsfs and others. I don't currently have any figures that I can share directly, and none which are likely to be directly comparable to your array. Is this RHEL/Centos 6 or Fedora/upstream, btw? If so then there are tracepoints available which can be used to time certain aspects of the internal performance of GFS2 which may help in narrowing down the problem. Another possible test is to use the seekwatcher script to gather blktrace data and produce a graph of I/O on the filesystem in order to see whether there are any issues with I/O being fragmented, Steve. -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
