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

mark m.roth at 5-cent.us
Thu Jul 26 23:29:41 UTC 2012


On 07/26/12 16:25, Allen Chen wrote:
> On 07/26/2012 03:19 PM, m.roth at 5-cent.us wrote:
>> Allen Chen wrote:
>>> On 07/11/2012 10:38 AM, m.roth at 5-cent.us wrote:
>>>>> From: Corey Kovacs<corey.kovacs at gmail.com>
>> <snip>
>>>>> On Tue, Jul 10, 2012 at 8:47 PM, mark<m.roth at 5-cent.us> 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?




More information about the redhat-list mailing list