Re: Bug 800181: NFSv4 on RHEL 6.2 over six times slower than 5.7
mark <[email protected]>
| Newsgroups | gmane.linux.redhat.general |
|---|---|
| Message-ID | <[email protected]> |
On 07/26/12 16:25, Allen Chen wrote: > On 07/26/2012 03:19 PM, [email protected] wrote: >> Allen Chen wrote: >>> On 07/11/2012 10:38 AM, [email protected] wrote: >>>>> From: Corey Kovacs<[email protected]> >> <snip> >>>>> On Tue, Jul 10, 2012 at 8:47 PM, mark<[email protected]> 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:[email protected]?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list