I am running some tests using 2.4.19 with all posted nfs patchs, =
everything is
being run sync. All runs are with NFS3 over UDP.
I have noticed that the IO rates (writes) start slowly (about =
1.5MB/second) and
slowly build up to a peak of 2.5MB/second over several minutes, with the
test averaging 2.32 MB/second over a 2GB file write. This is=20
with a server with Gigabit copper and the client with 100BT ethernet. =20
No packets are being lost from what I can tell, on either the server or=20
the client, both machines are dual cpu with 2GB of ram and otherwise=20
unloaded.
The 2.2.19 client (with almost no NFS patches) runs about 3.98MB/second =
over
a 2GB file write, against the same 2.4.19 NFS server, and hits that rate =
almost immediately.
Using an older 2.4.19 NFS server (that I don't believe has any extra NFS
patches) gets a rate of 6.50 average over a 2GB file from
a 2.2.19 client and gets 2.00 MB/second average from one of the
original 2.4 test clients.
Both rsize and wsize are 8192, I have tried it with 32768 on at least
the 2.4 client side, but it does not appear to affect the above results.
I am tried with 32 and 64 nfsd and this did not appear to change
any of the results. The rmem/wmem parameters have been upped
to 256K and did not appear to make any difference on the server.
The disk is locally capable of 20MB/second writes over a 4GB file, using
the same test as was used above.
Is there a way to make the IO start fast and stay fast? What code =
could
I look at to see if I can affect the way this works? Any parameters =
that
I could try changing that might improve things?
It appears to partially be client issue since the 2.2.19 NFS client is =
noticeably
faster, but since the older 2.4.19 server and the 2.2.19 client is even =
faster it
appears to also be a server issue.
So in summary:
2.2.19 -> 2.4.19 no patches -> 6.5MB/second
2.4.19nfsall -> 2.4.19 no patches -> 2.00 MB/second
2.2.19 -> 2.4.19 nfsall patch -> 3.98MB/second
2.4.19nfsall -> 2.4.19 nfsall patch -> 2.32 MB/second
Roger
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Roger A Heflin <Heflin> writes:
> I have noticed that the IO rates (writes) start slowly (about
> 1.5MB/second) and slowly build up to a peak of 2.5MB/second
> over several minutes, with the test averaging 2.32 MB/second
> over a 2GB file write. This is with a server with Gigabit
> copper and the client with 100BT ethernet. No packets are
> being lost from what I can tell, on either the server or the
> client, both machines are dual cpu with 2GB of ram and
> otherwise unloaded.
Have you enabled CONFIG_HIGHMEM? If so, could you please try disabling
it.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, 2002-10-04 at 16:46, Trond Myklebust wrote:
> Have you enabled CONFIG_HIGHMEM? If so, could you please try disabling
> it.
What's the issue with CONFIG_HIGHMEM, and on which machine should it be
expected to make a difference?
<b
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Bryan O'Sullivan <[email protected]> writes:
> On Fri, 2002-10-04 at 16:46, Trond Myklebust wrote:
>> Have you enabled CONFIG_HIGHMEM? If so, could you please try
>> disabling it.
> What's the issue with CONFIG_HIGHMEM, and on which machine
> should it be expected to make a difference?
I'm seeing major slowdowns, mainly on NFS reads, when I enable
CONFIG_HIGHMEM. I haven't yet had time to investigate this.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sat, 2002-10-05 at 09:18, Trond Myklebust wrote:
> I'm seeing major slowdowns, mainly on NFS reads, when I enable
> CONFIG_HIGHMEM. I haven't yet had time to investigate this.
I'll try to take a look on a local system in the next few days. Are you
or Roger using Jens Axboe's block-highmem patch or any of the drivers it
touches? Knowing this should help control for at least one variable.
<b
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Bryan O'Sullivan <[email protected]> writes:
> I'll try to take a look on a local system in the next few days.
> Are you or Roger using Jens Axboe's block-highmem patch or any
> of the drivers it touches? Knowing this should help control
> for at least one variable.
I've seen the behaviour on stock 2.4.19 and 2.4.20-preX. I haven't
tested any of Jens' patches...
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sat, Oct 05, 2002 at 11:51:29PM +0200, Trond Myklebust wrote:
> >>>>> " " == Bryan O'Sullivan <[email protected]> writes:
>
> > I'll try to take a look on a local system in the next few days.
> > Are you or Roger using Jens Axboe's block-highmem patch or any
> > of the drivers it touches? Knowing this should help control
> > for at least one variable.
>
> I've seen the behaviour on stock 2.4.19 and 2.4.20-preX. I haven't
> tested any of Jens' patches...
>
It must be a new bug. I used to have Quad P/II Xeon with 8GB RAM.
I had no problem with its NFS server performance. Also my modified
kernel based on RedHat kernel 2.4.18-14 has no NFS server problem
with 1.5GB RAM.
H.J.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
The only extra patches to 2.4.19 are the NFS patches, so
I don't believe so unless it was included in 2.4.19.
We are using config_himem, because at least some of the
machines we have will have a bit too much memory.
I will try turning that off and see if it makes a difference, is
this on the client or the server or both? I am pretty sure
we have it enabled on all of the nfsall patched 2.4.19 builts.
Roger
> -----Original Message-----
> From: Bryan O'Sullivan [SMTP:[email protected]]
> Sent: Saturday, October 05, 2002 3:55 PM
> To: Trond Myklebust
> Cc: Heflin, Roger A.; [email protected]
> Subject: Re: [NFS] 2.4.19 NFSALL performance oddity
>=20
> On Sat, 2002-10-05 at 09:18, Trond Myklebust wrote:
>=20
> > I'm seeing major slowdowns, mainly on NFS reads, when I enable
> > CONFIG_HIGHMEM. I haven't yet had time to investigate this.
>=20
> I'll try to take a look on a local system in the next few days. Are =
you
> or Roger using Jens Axboe's block-highmem patch or any of the drivers =
it
> touches? Knowing this should help control for at least one variable.
>=20
> <b
>=20
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sat, 2002-10-05 at 16:41, H. J. Lu wrote:
> It must be a new bug. I used to have Quad P/II Xeon with 8GB RAM.
> I had no problem with its NFS server performance. Also my modified
> kernel based on RedHat kernel 2.4.18-14 has no NFS server problem
> with 1.5GB RAM.
You're not using Trond's NFS_ALL patch, though, right? That has some
substantial modifications to the source.
<b
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sat, Oct 05, 2002 at 09:01:02PM -0700, Bryan O'Sullivan wrote:
> On Sat, 2002-10-05 at 16:41, H. J. Lu wrote:
>
> > It must be a new bug. I used to have Quad P/II Xeon with 8GB RAM.
> > I had no problem with its NFS server performance. Also my modified
> > kernel based on RedHat kernel 2.4.18-14 has no NFS server problem
> > with 1.5GB RAM.
>
> You're not using Trond's NFS_ALL patch, though, right? That has some
> substantial modifications to the source.
>
RedHat 2.4.18-14 is kernel 2.4.18 + tons of patches. I don't think
it has straight Trond's NFS_ALL patch. But it does have some NFS
changes. The only NFS related complaint I have is they default the
NFS V3 block size to 4096 which kills the NFS client performance. I
believe they put that in to avoid crashing NetApp. I changed it to
8192 and I am quite happy with its NFS performance.
H.J.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sat, 2002-10-05 at 14:51, Trond Myklebust wrote:
> I've seen the behaviour on stock 2.4.19 and 2.4.20-preX.
That tends to rule out the block-highmem stuff, at least, since it's
been in since 2.4.20-pre2.
<b
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs