From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Grzegorz Tylenda <beh@freya.dsv.agh.edu.pl>
Cc: nfs@lists.sourceforge.net
Subject: Re: nfs client performance - 2.4 vs 2.6
Date: Wed, 07 Jun 2006 11:10:44 -0400 [thread overview]
Message-ID: <1149693044.26188.3.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0606071256140.17804@freya.dsv.agh.edu.pl>
On Wed, 2006-06-07 at 14:14 +0200, Grzegorz Tylenda wrote:
> Hello,
>
>
> I noticed that after kernel version was changed from 2.4 to 2.6
> on clients connecting to filer, number of nfs ops on the filer heavily
> increase (about 40%). Overall filer load increase too. Statistic for both kernel series are very
> different.
>
>
> For example for 2 identical servers doing the same work, wchich differs
> only in kernel version generetes drasticly different number of
> NFSOPS:
>
> 12.456.678.8 2.4-server NFSOPS = 280165 ( 0%)
> 12.456.678.9 2.6-server NFSOPS = 3357591 ( 2%)
>
>
> Per host statistics looks like that (NFSv2 are cuted off, since I use
> NFSv3 only):
>
> filer*> nfsstat -h 2.4-server
>
> Client: 12.456.678.8 (2.4-server)
> ------------------------------------
>
> Server rpc:
> TCP:
> calls badcalls nullrecv badlen xdrcall
> 280355 0 0 0 0
>
> UDP:
> calls badcalls nullrecv badlen xdrcall
> 0 0 0 0 0
>
> Server nfs:
> calls badcalls
> 280355 0
>
>
> Server nfs V3:
> null getattr setattr lookup access readlink read
> 0 0% 131820 47% 0 0% 88459 32% 47558 17% 18 0% 12500 4%
> write create mkdir symlink mknod remove rmdir
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
> rename link readdir readdir+ fsstat fsinfo pathconf
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
> commit
> 0 0%
>
> Read request stats (version 3)
> 0-511 512-1023 1K-2047 2K-4095 4K-8191 8K-16383
> 16K-32767 32K-65535 64K-131071
> 0 0 0 0 3910 8590 0
> 0 0
> Write request stats (version 3)
> 0-511 512-1023 1K-2047 2K-4095 4K-8191 8K-16383
> 16K-32767 32K-65535 64K-131071
> 0 0 0 0 0 0 0
> 0 0
>
>
>
> filer*> nfsstat -h 2.6-server
>
> Client: 12.456.678.9 (2.6-server)
> ------------------------------------
>
> Server rpc:
> TCP:
> calls badcalls nullrecv badlen xdrcall
> 3365218 0 0 0 0
>
> UDP:
> calls badcalls nullrecv badlen xdrcall
> 0 0 0 0 0
>
> Server nfs:
> calls badcalls
> 3365218 0
>
> Server nfs V3:
> null getattr setattr lookup access readlink read
> 0 0% 52092 2% 0 0% 51149 2% 3253489 97% 6 0% 8482 0%
> write create mkdir symlink mknod remove rmdir
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
> rename link readdir readdir+ fsstat fsinfo pathconf
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
> commit
> 0 0%
>
> Read request stats (version 3)
> 0-511 512-1023 1K-2047 2K-4095 4K-8191 8K-16383
> 16K-32767 32K-65535 64K-131071
> 330 207 342 593 860 6150 0
> 0 0
> Write request stats (version 3)
> 0-511 512-1023 1K-2047 2K-4095 4K-8191 8K-16383
> 16K-32767 32K-65535 64K-131071
> 0 0 0 0 0 0 0
> 0 0
>
>
>
> As you can see on 2.6 kernel, about 97% are "access" request, while on
> 2.4 "access" are only 17%. Where this differences came
> from? Why 2.6 kernels generates 10x more request then 2.4?
>
> Client mounting opions are:
> ro,v3,rsize=8192,wsize=8192,acregmin=85,acregmax=180,acdirmin=85,acdirmax=180,hard,intr,nocto,lock,proto=tcp
>
> Changin rsize and wsize to 32k does not help, also different version of
> 2.6 series does not make a diffrence (curently 2.6.16.18) :(
>
> I will be grateful for any help.
2.4 kernels did not use 'access' to check for permissions except in the
case of root access, but relied (wrongly!) on the mode bits.
2.6 kernels do use access, but are supposed to cache the results. What
kind of a workload are you running on these clients?
Cheers,
Trond
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2006-06-07 15:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-07 12:14 nfs client performance - 2.4 vs 2.6 Grzegorz Tylenda
2006-06-07 15:10 ` Trond Myklebust [this message]
2006-06-12 9:01 ` Grzegorz Tylenda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1149693044.26188.3.camel@localhost \
--to=trond.myklebust@fys.uio.no \
--cc=beh@freya.dsv.agh.edu.pl \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.