Re: Improving FreeBSD NFS performance (esp. directory updates)

2003-06-06 Thread Thomas A. Limoncelli
On Thu, May 29, 2003 at 04:05:04PM -0500, Marc Wiz wrote:
> On Thu, May 29, 2003 at 04:54:00PM -0400, Tom Limoncelli wrote:
> > I have a NFS server with (so far) a single NFS client.  Things work 
> > fine, however if (on the client) I do an "rm -rf foo" on a large (deep 
> > and wide) directory tree the tty receives "NFS server not 
> > responding"/"NFS server ok" messages.
> > 
> > I don't think the network is at fault, nor is the server really going 
> > away.  I think the client is just impatient.  Is there a way to speed 
> > up a large "rm -rf"?  I have soft-writes enabled but alas
> 
> Tom,
> 
> please reproduce the problem but before doing it run the following commands
> and save the output:
> 
> On the client:
> 
> nfsstat -c
> netstat -m
> netstat -s
> 
> On the server:
> 
> nfsstat -s
> netstat -m
> netstat -s
> 
> Run the rm -rf /foo
> 
> Rerun the above commands on both the client and server and of course
> save the output again :-)
> 
> RTFM-ing for nfsstat I am disappointed that nfsstat does not have -z 
> option for zeroing out the counters.  Time to look at the source :-)

It turns out the issue isn't only the "rm -rf", so I've eliminated
that.  The process is creating many subdirectories and files.

Here's the output that you requested.  I've generated the output
at a "baseline", 1 minute into the process, and then every 4 hours.
Sorry for the flood of information but I figure "more is better".
You can look at the first and last items if you prefer.

I really appreciate the help!
--tal

-- 
Tom Limoncelli -- [EMAIL PROTECTED]  --  www.lumeta.Com


# CLIENT BASELINE:
Thu Jun  5 01:41:32 UTC 2003
Client Info:
Rpc Counts:
  Getattr   SetattrLookup  Readlink  Read WriteCreateRemove
 16222151  2470   9976708 91232  23111364  23342730544746 51291
   Rename  Link   Symlink Mkdir Rmdir   Readdir  RdirPlusAccess
  385 0 11004760080 13602 16651 0  69815088
MknodFsstatFsinfo  PathConfCommitGLeaseVacate Evict
030962158 0  21980734 0 0 0
Rpc Info:
 TimedOut   Invalid X Replies   Retries  Requests
0 0 0   239 166249915
Cache Info:
Attr HitsMisses Lkup HitsMisses BioR HitsMisses BioW HitsMisses
359087567  84614481 137095640   9976703 201904089  23084158  15151506  23342730
BioRLHitsMisses BioD HitsMisses DirE HitsMisses
  5296031 91232817844 16635 53658 0
257/608/18240 mbufs in use (current/peak/max):
257 mbufs allocated to data
256/312/4560 mbuf clusters in use (current/peak/max)
776 Kbytes allocated to network (5% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
tcp:
205722821 packets sent
155645171 data packets (2158194817 bytes)
109 data packets (89632 bytes) retransmitted
0 resends initiated by MTU discovery
34720623 ack-only packets (365546 delayed)
0 URG only packets
0 window probe packets
15355469 window update packets
1449 control packets
213168802 packets received
152983420 acks (for 2158194689 bytes)
1424 duplicate acks
0 acks for unsent data
208828275 packets (1042433032 bytes) received in-sequence
3 completely duplicate packets (192 bytes)
0 old duplicate packets
0 packets with some dup. data (0 bytes duped)
62 out-of-order packets (5136 bytes)
0 packets (0 bytes) of data after window
0 window probes
62774 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
671 connection requests
119 connection accepts
1 bad connection attempt
0 listen queue overflows
790 connections established (including accepts)
777 connections closed (including 2 drops)
202 connections updated cached RTT on close
202 connections updated cached RTT variance on close
3 connections updated cached ssthresh on close
0 embryonic connections dropped
152983420 segments updated rtt (of 149305673 attempts)
74 retransmit timeouts
1 connection dropped by rexmit timeout
0 persist timeouts
0 connections dropped by persist timeout
31 keepalive timeouts
31 keepalive probes sent
0 connections dropped by keepalive
3834814 correct ACK header predictions
60088755 correct data packet head

Re: Improving FreeBSD NFS performance (esp. directory updates)

2003-05-30 Thread Marc Wiz
On Thu, May 29, 2003 at 04:54:00PM -0400, Tom Limoncelli wrote:
> I have a NFS server with (so far) a single NFS client.  Things work 
> fine, however if (on the client) I do an "rm -rf foo" on a large (deep 
> and wide) directory tree the tty receives "NFS server not 
> responding"/"NFS server ok" messages.
> 
> I don't think the network is at fault, nor is the server really going 
> away.  I think the client is just impatient.  Is there a way to speed 
> up a large "rm -rf"?  I have soft-writes enabled but alas

Tom,

please reproduce the problem but before doing it run the following commands
and save the output:

On the client:

nfsstat -c
netstat -m
netstat -s

On the server:

nfsstat -s
netstat -m
netstat -s

Run the rm -rf /foo

Rerun the above commands on both the client and server and of course
save the output again :-)

RTFM-ing for nfsstat I am disappointed that nfsstat does not have -z 
option for zeroing out the counters.  Time to look at the source :-)

Marc (who in a former life and now current life is doing NFS support)
-- 
Marc Wiz
[EMAIL PROTECTED]
Yes, that really is my last name.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Improving FreeBSD NFS performance (esp. directory updates)

2003-05-30 Thread Tom Limoncelli
I have a NFS server with (so far) a single NFS client.  Things work 
fine, however if (on the client) I do an "rm -rf foo" on a large (deep 
and wide) directory tree the tty receives "NFS server not 
responding"/"NFS server ok" messages.

I don't think the network is at fault, nor is the server really going 
away.  I think the client is just impatient.  Is there a way to speed 
up a large "rm -rf"?  I have soft-writes enabled but alas

Details:
The server is an Intel Xeon CPU 2.20GHz running FreeBSD 4.8 (updated to 
the latest RELENG_4_8 release yesterday).  It has a 1000TX interface to 
a Cisco switch.  The partition is part of a SCSI RAID unit (160MB/s 
transfer rate, Tagged Queueing enabled).  The partition that is 
exported to the client is:

# mount | egrep e2
/dev/da0s1f on /e2 (ufs, NFS exported, local, soft-updates)
/etc/rc.conf lists:
nfs_server_flags="-u -t -n 16"
The client is a (accoriding to dmesg) "Pentium III/Pentium III 
Xeon/Celeron (934.99-MHz 686-class CPU)" running FreeBSD 4.7-RELEASE.  
amd is configured to mount the partion with 
"opts:=rw:nfs_proto=udp;nfs_vers=3".
/etc/rc.conf lists:
	nfs_client_flags="-n 4"

Any tuning suggestions?

--tal

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"