rlogin jobs has different performance.

[jane zhang]

Hi all,
One of my user reports to me when he rlogin in several machines to run simulation jobs simutanously, one remote box always run very fast and the others seem to be frozen.

I changed the /etc/exports to allow asychonous write on the NFS server( where his home directory is), but the file system is HFS and fs_async is 0.

/homes -access=netgroupname,async

My question is:
what do you think why one machine is very quick while others are very slow?

Do I need to set fs_async 1 in order for NFS asynchronous writes work? if so, what is the procedure to change the kernal parameter ( details using sam or command line please) The box can tolerate downtime.

Thanks,

[Steven E. Protter]

Are the machines the same cpu and memory?

If so, what are the load factors on the machines.

I am attaching a HP-UX script you can run background on both machines and collect some data that might be useful.

SEP

[Robert-Jan Goossens]

Hi,

as Steven mentioned performance on the servers, but you could also check the network settings 10/100mb, half/full duplex speed and autonegation on/off on the servers and the switches.

Kind regards,

Robert-Jan.

[S.K. Chan]

The get a good answer out of this you need to describe the nature of the application/script/program that you're running on your machine. Are these machines similar in terms of it's hardware configurations, OS, patches , etc, etc. To answer your other question, setting fs_async to 1 improves io performance but it has a risk of leaving your FS (HFS) in a corrupted state in a crash situation (ie fsck is not able to do its job well). So it's a decision you have to make .. performance vs FS-integrity. To change set fs_async to 1.
Manually (11i)
==============
# cd /stand/build
# /usr/lbin/sysadm/system_prep -v -s system
# kmtune -S /stand/build/system -s fs_async=1
# /usr/sbin/mk_kernel -s ./system
# mv /stand/system /stand/system.prev
# kmupdate
# shutdown -ry 0
SAM
===
Kernel Config->Configurable PArameter
Select "fs_async"->Action->Modify.
Action->Process New Kernel
You'll be prompted to reboot afterwards.

[Steven E. Protter · Accepted solution]

Robert is right, thats a very common cause.

Check the lanadmin -x 0 (replace 0 with the actual lan number) on both servers. If the answer doesn't match, you have your explanation. On most modern servers you should be running 100 BaseT full duplex.

SEP

[jane zhang]

Hi all,
Thanks for the prompt responses.
The user is rlogin from hpux 10.20 to sun solaris 5.7. The fastest sun machine is newer than other 3. we are using NIS/NFS.

After I change the /etc/exports to allow async, the user told me the slow simulation jobs have significant progress.

So the conclusion is it is not necessary to set fs_async to 1 in order for NFS to work?

/homes -access=netgroupname,async

I also check hpbase100conf and HP_BASE100_DUPLEX[0]=full.

Jane

[Robert-Jan Goossens]

Hi Jane,

Could you specify the SUN servers and the options you use for NFS (-o bg -o rw etc.) solaris is kind of touchy for these settings.

I've had some problems on a E10000 last week, the nfs mounts almost died because i did not use the background option.

I suppose you have checked the patches on the sun side.

Like to know a bit more.

Robert-Jan.

[jane zhang]

Robert-Jan,
The Hpux is the NFS server and Sun workstation are the NFS client in this case.

Since we are using NIS/NFS/automount, every machine is NFS server as well as NFS client. and /homes are shared or exported.
# more sharetab
/homes - nfs rw=netgroupname home dirs

Jane

[S.K. Chan]

See doc (attached to my previous post) on troubleshooting NFS performance. Though it's for HPUX (10.x) the fundamentals are the same. It may help you to narrow the cause down.
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xae40ec08252fd611abd50090277a778c,00.html

[Bill Hassell]

NFS can be a very tortuous protocol to manage. I would suggest looking at the HP-UX NFS book by Dave Olker. You'll get a wealth of tips (and caveats) to managing NFS perfromance.

However, fs_async=1 is a risky setting. It will write filesystem structural changes into the buffer cache which does indeed improve write performance but with the serious risk of filesystem corruption that may not be fixable in case the system crashes. The reason is that critical information about the occupied and freespace in the filesystem may not have made it to the disk and the resultant corruption is beyond fsck repair.