Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Poor NFS client performance on AIX 4.3.3

45 views
Skip to first unread message

Andria Thomas

unread,
Jul 16, 2002, 3:00:16 PM7/16/02
to
Hello ---

I have read the many posts regarding poor NFS client performance, but
I have tried all the suggested fixes and still cannot see much
improvement. I am connecting to a FreeBSD NFS server, and no other
NFS clients (in a variety of operating systems) seem affected like our
one poor RS/6000.

I have tried the following:

1. Changing the number of biod daemons -- both lowering and raising
the number.
2. Increasing the following 'no' variables:
no -o tcp_sendspace=65536
no -o tcp_recvspace=65536
no -o udp_sendspace=32768
no -o udp_recvspace=65536
3. Using NFS version 2 instead of 3.
4. Changing the read and write buffer sizes to 2048 each and 8192
each.

Running 'entstat -t ent0' shows no significant errors of any kind, and
certainly no errors which would indicate hardware problems (such as
CRC errors, etc...) Other network traffic (i.e. ftp, etc...) works
fine. Reading files over nfs shows no discernable lag -- the problem
appears only when writing files.

The output of 'nfsstat -c' is as follows:

Client rpc:
Connection oriented
calls badcalls badxids timeouts newcreds badverfs
timers
965416 1 0 0 0 0 0
nomem cantconn interrupts
0 0 0
Connectionless
calls badcalls retrans badxids timeouts newcreds
badverfs
81993 0 0 0 0 0 0
timers nomem cantsend
0 0 0

Client nfs:
calls badcalls clgets cltoomany
883523 1 0 0
Version 2: (3081 calls)
null getattr setattr root lookup readlink read
0 0% 11 0% 0 0% 0 0% 41 1% 0 0% 1512
49%
wrcache write create remove rename link
symlink
0 0% 1508 48% 4 0% 0 0% 0 0% 0 0% 0 0%
mkdir rmdir readdir statfs
0 0% 0 0% 4 0% 1 0%
Version 3: (880444 calls)
null getattr setattr lookup access readlink read
0 0% 17815 2% 80302 9% 421940 47% 30041 3% 66421 7%
26680 3%
write create mkdir symlink mknod remove
rmdir
62645 7% 23983 2% 1014 0% 61668 7% 0 0% 53793 6% 646
0%
rename link readdir readdir+ fsstat fsinfo
pathconf
1512 0% 0 0% 985 0% 5943 0% 108 0% 5 0% 0 0%
commit
24943 2%

Any ideas for other things to try? I 6MB write over NFS takes between
15 seconds and over a minute -- significant enough for it to be a
major problem. I'd be grateful for any new ideas...

Thanks!
Andria

----------------------------------------------
Andria Thomas, Information Technology Manager
Blue Ridge Numerics
434-977-2764 x 118
andria...@cfdesign.com

Hans-Joachim Ehlers

unread,
Jul 16, 2002, 4:02:29 PM7/16/02
to
"Andria Thomas" <and...@brni.com> schrieb im Newsbeitrag
news:78c3b4eb.0207...@posting.google.com...

> Hello ---
>
> I have read the many posts regarding poor NFS client performance, but
> I have tried all the suggested fixes and still cannot see much
> improvement. I am connecting to a FreeBSD NFS server, and no other
> NFS clients (in a variety of operating systems) seem affected like our
> one poor RS/6000.
>

Check your ethernet hardware setting. You might have a misconfigured
network adapter/switch

* See "entstat" for network error details. In case you should have a full
duplexed network but a misconfiguration you will see src errors.
* Do a ftp put AND get to check performance. ( hash on )

Hajo

Douglas R. Probst

unread,
Jul 16, 2002, 4:34:31 PM7/16/02
to
Make sure all you network adapters are locked down at the speed of your
network switch and not set to Auto Neg.
Doug
"Andria Thomas" <and...@brni.com> wrote in message
news:78c3b4eb.0207...@posting.google.com...

Clive Sparkes

unread,
Jul 17, 2002, 3:20:55 AM7/17/02
to
and...@brni.com (Andria Thomas) wrote in message news:<78c3b4eb.0207...@posting.google.com>...

> Hello ---
>
> I have read the many posts regarding poor NFS client performance, but
> I have tried all the suggested fixes and still cannot see much
> improvement. I am connecting to a FreeBSD NFS server, and no other
> NFS clients (in a variety of operating systems) seem affected like our
> one poor RS/6000.
>
> I have tried the following:
>
> 1. Changing the number of biod daemons -- both lowering and raising
> the number.
> 2. Increasing the following 'no' variables:
> no -o tcp_sendspace=65536
> no -o tcp_recvspace=65536
> no -o udp_sendspace=32768
> no -o udp_recvspace=65536
> 3. Using NFS version 2 instead of 3.
> 4. Changing the read and write buffer sizes to 2048 each and 8192
> each.
>
< snip >

You could try tuning the write buffer size to fit the mtu. ie, wsize=1400

--
Regards,
Clive

Andria Thomas

unread,
Jul 17, 2002, 9:33:12 AM7/17/02
to
Thanks for all the replies. In response to the concerns about
hardware, an ftp put takes roughly the same time as an ftp get (about
1MB/sec), and there are no "errors" listed in the output of entstat.
However, the "interrupts" field is high for both transmits and
receives -- is that normal?

As far as turning off Auto-Negotiate on the network adapter, I did
this for our other RS/6000 (and it did fix the problem), but on this
one that doesn't seem to be an option anywhere in smit. I've looked
under "devices -- communication -- ethernet adapter", but all I see is
the following:

Ethernet Adapter ent0
Description Integrated
Ethernet Ad>
Status Available
Location 00-00-0E
TRANSMIT queue size [512]
+#
Enable ALTERNATE ETHERNET address no
+
ALTERNATE ETHERNET address [0x]
+
Apply change to DATABASE only no

Does this mean that the card is set to auto-negotiate by default, or
am I just looking in the wrong place? I've also looked under
"Communication --> TCP/IP", but see nothing there about duplex
settings either.

I'm attaching the output of 'entstat -t ent0' below. Any help is
appreciated!

Andria


Transmit Statistics: Receive Statistics:
-------------------- -------------------
Packets: 2067301 Packets: 2685610
Bytes: 1415419398 Bytes: 699332240
Interrupts: 2067301 Interrupts: 2684902
Transmit Errors: 0 Receive Errors: 0
Packets Dropped: 0 Packets Dropped: 0
Bad Packets: 0
Max Packets on S/W Transmit Queue: 60
S/W Transmit Queue Overflow: 0
Current S/W+H/W Transmit Queue Length: 0

Broadcast Packets: 35678 Broadcast Packets:
734777
Multicast Packets: 4 Multicast Packets: 2
No Carrier Sense: 0 CRC Errors: 0
DMA Underrun: 0 DMA Overrun: 0
Lost CTS Errors: 0 Alignment Errors: 0
Max Collision Errors: 0 No Resource Errors: 0
Late Collision Errors: 0 Receive Collision
Errors: 0
Deferred: 88444 Packet Too Short Errors:
0
SQE Test: 0 Packet Too Long Errors:
0
Timeout Errors: 0 Packets Discarded by
Adapter: 0
Single Collision Count: 6888 Receiver Start Count: 1
Multiple Collision Count: 18268
Current HW Transmit Queue Length: 8

General Statistics:
-------------------
No mbuf Errors: 0
Adapter Reset Count: 0
Driver Flags: Up Broadcast Running
Simplex AlternateAddress

Hans-Joachim Ehlers

unread,
Jul 17, 2002, 10:53:21 AM7/17/02
to
Its look like that your onboard ethernet adapter does only support 10 MB (10
MegaBits ~ 1 MegaByte) half duplex.
Your entstat output shows that your adapter is working in half duplex mode
"...Single Collision Count: 6888 "
Do a check with "lsattr -El ent0 , lscfg -vl ent0 " to see all possible
settings.
Also check your machine manual about the possiblities to change the speed of
your adapter.
Verify the setting on your switch. So switch and network card are set equal.
Maybe you must get an extra network card.

Hajo

"Andria Thomas" <and...@brni.com> schrieb im Newsbeitrag

news:78c3b4eb.02071...@posting.google.com...


> Thanks for all the replies. In response to the concerns about
> hardware, an ftp put takes roughly the same time as an ftp get (about
> 1MB/sec), and there are no "errors" listed in the output of entstat.

Do you mean "1 MBit or 1 MByte" ?

0 new messages