Your email explains a fair amount and here are two reasons contributing to this.
One is the mdc semaphore - our clients are effectively single threading metadata updates - it will be a little while before we get to this, it is not that hard. The second is that many operations (but not the most critical open/create/read/write) have too many RPC's - this one we have a good plan for, and I think it might be fixed quite soon. Thanks! - Peter - > -----Original Message----- > From: Jean-Marc Saffroy [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 04, 2006 9:59 AM > To: Peter J. Braam > Cc: 'Andreas Dilger'; 'Lin Shen (lshen)'; 'Lustre User > Discussion Mailing List' > Subject: RE: [Lustre-discuss] Lustre Lite > > On Sat, 4 Nov 2006, Peter J. Braam wrote: > > > Do you have a test on which NFS performs much better. We'd like to > > know more about that. > > One test I can mention is postmark, originally written by > Netapp folks, now available from Debian: > http://packages.debian.org/stable/utils/postmark > > In the test, postmark was configured to perform 10k > "transactions" on 10k files between 500B and 22kB. > > This was run with up to 16 processes on *one* client > connecting to various server configs on several interconnects > and storage systems, running 1.4.6 and 1.6beta4. > > For convenience, I wrote the attached wrapper script: > $ ssh $client postmark.sh -n 10000 -t 10000 -j $numprocs > $log > > The metric was the number of transactions per second (sum of > column 3 across all lines of $log). NFS reached 800-1000 t/s > with 2-8 processes (then performance dropped) over GigE, > while Lustre peaked at 200 t/s with > 2 process on a tiny GigE cluster (1 MDS, 1 OSS serving 1 > OST). A bigger cluster could not give more than 900 t/s. > > Back then I suspected that the test was probably network > bound (because of high interrupt and packet rates vs. low CPU > and disk usage), but I could not find a good measurement. A > tool showing metadata RPC statistics (such as LMT maybe, but > I didn't know it then) would have been useful. > > > If you go bak on this list, you will see that Lustre can handsomely > > beat NFS at unpacking archives, for example. So I am curious. > > I suppose you refer to the thread "I/O performance on small > files" (end of June). IIRC the recipes mentioned there had > been used in the tests. > > Now I no longer have time to spend on these issues, but ideas > for improvement would still be interesting. > > > -- > Jean-Marc Saffroy - [EMAIL PROTECTED] _______________________________________________ Lustre-discuss mailing list [email protected] https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
