NFS problem

[Ionut Grigorescu_2]

Hello,

I have a system containing 2 NIS and NFS HPUX11.00 servers and 3 HPUX 11.00 workstations.
The workstations are configured as NFS CLIENT. Directory /d/home on the NFS server is exported to the clients. When I'm working in /m/home (on the clients) and I try to copy a file or I'm working on a file and try to save with ANOTHER name, it takes an eternity (well, at least 5 minutes, even the file is about 20...50kB). I have notticed that in the /etc/rc.config.d/nfsconf the AUTOFS is set to 0 on the servers and to 1 on the clients. Also
# rpcinfo -u cusapp2 nfs
command issues a:
rpcinfo: RPC: Program not registered
program 100003 is not available,
where cusapp2 is a client.
What can I do further?

[Michael Elleby III_1]

Hello-

From the client, execute 'showmount -e nfs_server_name' and see what it returns, if it does not work, then check to see if nslookup work properly:

- running nslookup on the client to look for the server
-running nslookup on the server to look for the clients?

Mike-

[Ionut Grigorescu_2]

nslookup works properly. Also the mounted file system are available. The only problem is that, when I tried to copy a file to that mounted filesystem it take a looooooong time. On the nfs servers MC Service Guard is running and the exportfs for /d/home and 2 another filesystems is performed by MC SG.(there is a conf file in /etc/cmcluster)

[Craig Rants]

A good NFS Troubleshooting doc.

http://docs.hp.com/hpux/onlinedocs/B1031-90048/00/00/42-con.html

GL,
C

[Ionut Grigorescu_2]

Thanks for the info, I have the book,but I couldn't solve the problem with that. I'm still digging...

[S.K. Chan]

Running the rpcinfo from the server should give you ..
"program 100003 version 2 ready and waiting"
or
"program 100003 version 3 ready and waiting"
On the client when you run ..
# rpcinfo -p|grep nfs
do you get anything ? If the answer is no, try to restart the nfs services on the client side. Before you do that (restart NFS) make sure all exported FS are unmounted.
# /sbin/init.d/nfs.server stop
# /sbin/init.d/nfs.client stop
# /sbin/init.d/nfs.server start
# /sbin/init.d/nfs.client start

[Vincent Fleming · Accepted solution]

Unfortunately, there is rarely a quick answer to your type of problem - it can have many causes.

Typically, your problem is caused by a timeout of some sort. Most often the culprit is DNS or NIS servers not responding, responding with incorrect information, etc.

What I'm saying here is not to concentrate on the NFS, but on other services such as the NIS. Make sure they're working properly and returning valid information.

Most of the time when NFS itself breaks, you get console messages such as "Server Not Responding" and it just doesn't work (I/O errors and all that). Being slow is something very different - because it still works, but is slow.

If you haven't already, try following that link above and go to the section on debugging NIS servers.

If you have a network sniffer of some sort, it can help a lot to see what your client is sending that it's waiting on... (the last thing it sends before the hang), which can lead you directly to the problem.

Let us know how you make out.

Good luck!

[Ionut Grigorescu_2]

Hi,

you are right, I'm also thinking that can be another problem not only nfs. I have sniffed with Ethereal. I have logged on 10.1.30.12 - nfs client and I have copied in /m/home a file to file_old. First attempt was a 40k file then a 300k. First file was coppied in about 3 minutes, second is still not coppied (!!). In the Ethereal trace I have found that V3 Write Call are answered (V3 Write Reply)sometimes immediately (msec), sometime after 5-7 minutes(!). The write requests are sent by the client 10.1.30.12 to the nfs server 10.1.30.21, which is a MC Service Guard package running on 10.1.30.18 (HP-UX server). The replies are sent back by 10.1.30.18 to 10.1.30.12. The copy time increases with the file size, but the ethernet interfaces are all set to 100M. I do not have any valuable entry in syslog associated to this problem .
Do you have any further suggestion?

[Ionut Grigorescu_2]

Oh, I've forgot one thing - in Ethereal trace, after delayed Write Replies come some ICMP Time-to-live exceeded from 10.1.30.18 to 10.1.30.12...

[V. Nyga]

Hi,

you should not only check if the interfaces are running 100MB but also if they are running Full-Duplex or Half-Duplex - also for the hubs.
This problem I always have.

Regards
Volkmar

[U.SivaKumar_2]

Hi,

How many nfsd instances are running ? . Try increasing the Instances .

Monitor the server I/O load and buffer stats when writing to the NFS directory.
#nfstat -s

#iostat 1 20

#sar 1 10

Try running few biod daemons on the client side.

What is your value of kernel parameter dbc_max_pct ?

regards,
U.SivaKumar

[Ionut Grigorescu_2]

I had only one instance of nfskd and none of nfsd. I have created 2 instances of nfsd and started a file copy.
Results of sar 1 20 - 100% idle,
dbc_max_pct=30

[U.SivaKumar_2]

Hi,
Increase the number of nfsd daemons and see if it makes any difference.
Also try using biod daemons on the client side.

IS your server , Busy NFS server serving lot of
nfs clients ?. how many clients ?. I would suggest to increase your buffer cache . dbc_max_pct from 30% to 60% for more NFS performance.


regards,
U.SivaKumar

[Ionut Grigorescu_2]

It is a server with 6 clients. I do not think it is so busy. I shall compare the config files with those for another similar system. Thank you.