does your DNS reverse lookup work correctly?
Main Topics
Browse All TopicsWe moved our office a few weeks ago, and as part of that move, re-ip'd the whole environment from a 10.0.0.x range to a 192.168.0.x range.
Since then, we've had performance issues on Solaris, AIX, and HP-UX NFS clients. Our linux clients are as well-behaved as they ever were.
We get a lot of RPC timeouts, and very slow performance on the NFS mounted directories. Have tried playing with vers=2/vers=3 and tweaking the wsize/rsize params, but so far, no luck.
Looking for any suggestions or ideas... Since the linux environments remain fast, I think we can safely rule out a network or hardware issue, so I'm thinking it's on the nfs clients themselves.
netstat -i shows no collisions on the interfaces themselves.
nfsstat from the client shows a lot of badcalls and badxids:
# nfsstat -rc
Client rpc:
Connection oriented:
calls badcalls badxids timeouts newcreds badverfs timers
27347 2599 537 2563 0 0 0
cantconn nomem interrupts
0 0 17
Connectionless:
calls badcalls retrans badxids timeouts newcreds badverfs
9 1 0 0 0 0 0
timers nomem cantsend
6 0 0
Finally, a truss of a cp from an NFS mount to local disk on the client hangs on the following line:
write(4, 0xFE800000, 8388608) (sleeping...)
We have a fairly heterogenous environment, and the NFS servers in question are a linux-based Snap Server, and a stock Solaris 8 box with clients running linux, solaris, HP-UX, and AIX. None of these issues were present in the old environment, and the linux clients are all still happy.
Looking for any ideas...
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Doesn't look limk PMTU issues:
# ping -sn nfsserver 9000
PING nfsserver (192.168.0.50): 9000 data bytes
9008 bytes from 192.168.0.50: icmp_seq=0. time=2.96 ms
9008 bytes from 192.168.0.50: icmp_seq=1. time=2.53 ms
...
----nfsserver PING Statistics----
13 packets transmitted, 13 packets received, 0% packet loss
round-trip (ms) min/avg/max/stddev = 2.52/2.565/2.96/0.120
Max size, non fragmenting is 1472 (standard MTU of 1500 less the 28 byte header).
Packets larger than that don't go.
C:\ping -l 1473 -f wise
Pinging wise [192.168.0.50] with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.0.50:
Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
did you reset *all* switches (see http:#16417635)
another reason might be a routing problem, check with traceroute from both ends
Can someone shed some light on this? I flipped the interface on one of the nfs servers to the other nic on the assumption that we might have a bad nic.
It autonegotiated to 100-half-duplex (this is a Solaris 8 box) and things suddenly got a lot faster.
This box is plugged directly into a Cisco Catalyst 2950 XL switch... which should talk 100fd, but I can't argue with the results.
Why would 100hd be faster in this case when plugged into a switch?
hmm, sounds like the auto-negotation failed
try to install Ethtool http://freshmeat.net/redir
Catalyst always had serious problems with NWay. Install firmware newer than netcard or force both ends to same media/duplex.
- TCP Previous segment lost -> duplex prob
- TCP Dup ACK -> duplex prob
- TCP Retransmission -> duplex prob
- TCP Out-of-order -> normal work
- TCP Window Update -> normal work
bad checksums would note wire problem or node netcard checksum processor problems
Business Accounts
Answer for Membership
by: gheistPosted on 2006-04-08 at 08:44:27ID: 16407648
Maybe some TCP extension recently implemented in Linux, or PMTU blackhole.