NFS Memory Bottleneck on HPUX 11.0

[FRED Dennison]

Our Application gobbles up all of the Memory for User Processes, so whenever a Server attempts to access an NFS mounted directory with > 1000 entries, the process affected takes close to 100% cpu and about 30 seconds to produce an 'll' output. Unfortunately reducing the number of files is not an option.

Have considered increasing the Buffer Cache, but am unsure if this is the area that is short of space. Can anyone advise which area might need to be investigated?

[Steffi Jones_1 · Accepted solution]

I'm not really a network person, but you might want to consider checking the patchlevel of NFS for your systems.

here is the list of nfs patches for 11.0 including all dependencies:System: 800, HPUX: 11.00

PHCO_20531 s700_800 11.00 mount(1M) cumulative patch
PHKL_18543 s700_800 11.00 PM/VM/UFS/async/scsi/io/DMAPI/JFS/perf patch
PHKL_19202 s700_800 11.00 fsadm panic if extending root on 11.x
PHKL_20016 s700_800 11.00 2nd CPU not recognized in G70/H70/I70
PHKL_20202 s700_800 11.00 Fix pthread error return, nfs/tcp panic
PHNE_20316 s700_800 11.00 Cumulative STREAMS Patch
PHCO_20531 s700_800 11.00 mount(1M) cumulative patch
PHNE_20949 s700_800 11.00 HyperFabric B.11.00.0[0-8] cumulative patch
PHCO_21187 s700_800 11.00 cumulative SAM/ObAM patch
PHKL_21511 s700_800 11.00 Fix VM page read-ahead panic
PHKL_22097 s700_800 11.00 fixes in MVFS, rcp, mmap and IDS/9000
PHNE_22125 s700_800 11.00 ONC/NFS General Release/Performance Patch
PHKL_22209 s700_800 11.00 fix f_cred, fork DPFs & accept(2) errors
PHCO_22274 s700_800 11.00 bdf(1M) cumulative patch
PHCO_22314 s700_800 11.00 libc cumulative patch
PHNE_22331 s700_800 11.00 LAN product cumulative patch
PHNE_22397 s700_800 11.00 cumulative ARPA Transport patch
PHKL_22432 s700_800 11.00 VxFS 3.1 icache cumulative patch
PHKL_22440 s700_800 11.00 VM,async,hyperfabric,ttrace
PHCO_22453 s700_800 11.00 fsck_vxfs(1M) cumulative patch
PHKL_22589 s700_800 11.00 LOFS, select(), IDS/9000 and umount race fix

Steffi Jones

[Trevor Dyson]

G'day Fred

->Our Application gobbles up all of the Memory for User Processes, so whenever a Server attempts to access an NFS mounted directory with > 1000 entries, the process affected takes close to 100% cpu and about 30 seconds to produce an 'll' output. Unfortunately reducing the number of files is not an option.

The description is a bit unclear to me. Is the 'll' that is using 100% cpu running on the NFS client or on the NFS server. (The NFS server is the system that exports the filesystem, the NFS client is the system mounting the NFS filesystem across the NW).

If the 'll' is running on the NFS client then this may be improved if you are currently using NFS V2 and you move to NFS V3 as V3 performance is much better.

This is just one of a whole swag of areas that I would investigate for NFS performance.

If you provide the following info then I may be able to help:

What version of HP-UX is being used on the NFS server and clients?

Is the performance of the NFS Server or NFS client the issue or is it a problem with both.

Regards,

Trevor

[Lasse Knudsen]

Look at this:

PHNE_20627:
libnfs.a
SR: 8606134214
DTS: JAGad03354
Extremely slow performance of commands or utilities
operating on large directories over NFS.

PHNE_20627 is superseded by PHNE_22125

[Dan Hetzel]

Hi Fred,

This is a known issue and is solved by patch PHNE_22125.

Check the following link as there are quite a lot of prerequisites.

Dan

http://europe-support2.external.hp.com/wpsl/bin/doc.pl/sid=d1b91a2c15573fae0a/screen=wpslCandidateList

[FRED Dennison]

Thanks all for your input on this topic.

I will rollout the patches within the next couple of weeks.

Cheers, FRED