Re: Bug 800181: NFSv4 on RHEL 6.2 over six times slower than 5.7

[mark <m.roth@xxxxxxxxx>]

On 07/26/12 16:25, Allen Chen wrote:
> On 07/26/2012 03:19 PM, m.roth@xxxxxxxxx wrote:
> > Allen Chen wrote:
> > > On 07/11/2012 10:38 AM, m.roth@xxxxxxxxx wrote:
> > > > > From: Corey Kovacs<corey.kovacs@xxxxxxxxx>
> > <snip>
> > > > > On Tue, Jul 10, 2012 at 8:47 PM, mark<m.roth@xxxxxxxxx> wrote:
> > > > <snip>
> > > > > > I'll say it one more time: we found the problem on CentOS. We went to
> > > > > > our test RHEL system. Updated it. Exported a directory *from* the
> > > > > > RHEL
> > > > > > box to itself, to /mnt/foo, and ran the test, and got the same
> > > > > > results.
> > > > > >
> > > > > > In fact, I ran it twice today, updating the kernel in between, and
> > > > > > with 6.3, it's taking a consistent 7.5 min, instead of the 6.5 we
> > > > > > were
> > > > > > getting with 6.2
> > > > > > <snip>
> > > > > >
> > > > > > Now, all that said and done, here are some questions for you which
> > > > > > might help us figure what would help.
> > > > > > > 1. What options are present on the mount? (cat /proc/mounts, thinks
> > > > > > > like sync can be a problem)
> > > > /scratch/foo<same_server>(rw,sync,no_wdelay)
> > <snip>
> > > > > > 2. What does your /etc/exports config look like on your server node
> > > > > > (cat /etc/exports)
> > <snip>
> > > > > > Do you mean selinux auditing? As I said, doing it on the local drive
> > > > > > takes seconds. Doing it from a 5.x NFS server takes about 1.5 min.
> > > > Therefore,
> > > > > > there's nothing that could affect it on the one server.
> > > I did a quick test on my CentOS 6.2, and I don't see any slow untar.
> > > Here are the steps I did:
> > >
> > > On server:
> > > # uname -a
> > > Linux backup62 2.6.32-220.el6.i686 #1 SMP Tue Dec 6 16:15:40 GMT 2011
> > > i686 i686 i386 GNU/Linux
> > >
> > > on my desktop:
> > > # uname -a
> > > Linux centos62 2.6.32-220.el6.i686 #1 SMP Tue Dec 6 16:15:40 GMT 2011
> > > i686 i686 i386 GNU/Linux
> > > # mount -t nfs server-ip:/images /mnt
> > > # time tar xvfz /mnt/hs21.tgz
> > > ...
> > > real 0m5.496s
> > > user 0m0.438s
> > > sys 0m0.176s
> > >
> > > # cd /mnt
> > > time tar xvfz hs21.tgz
> > > ...
> > > real 0m20.634s
> > > user 0m0.414s
> > > sys 0m0.135s
> > >
> > > # ll hs21.tgz
> > > -rw-r--r-- 1 root root 43725908 Apr 2 2008 hs21.tgz
> > Allen,
> >
> > what does /etc/exports read? On my system, if I have it as
> >
> > /scratch/foo<fwdn.hostname>(rw,sync,no_wdelay)
> >
> > I get the delay. Following someone's post a week or two ago, I tried
> > /scratch/foo<fwdn.hostname>(rw,async,no_wdelay)
> >
> > and it goes at a reasonable speed. That (a)sync seems to override
> > everything else. However, I'm trying to get together with my manager to
> > decide if we want to use async - that's above my pay grade, and we
> > have to
> > consider that we have a fair number of users that run jobs that run for
> > literally days, sometimes over a week, and loss of any data at all might
> > mean false results, or having to rerun it.
> > > Is there anything you can do with the DNS settings on the server side?
> > DNS has nothing to do with the test case.
> # cat /etc/exports
> /images 192.168.1.0/24(rw) 10.235.4.2/32(rw)

Since you're not specifying explicitly, I suspect it's doing async.

	mark


--
Why the Libertarian idea of a privatized courts won't work,
from a slogan from Kenya: why bother hiring a lawyer, when
you can buy a judge?

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list