poor NFS performance when retrieving directories WITH attributes

[Jan van den Ende]

Alex,

to begin with: Welcome to the OpenVMS Forum.
>>>
the share may contain up to 3000 directory entries in root level.
<<<

Have you tried an unqualified DIR vs directory/date/size/owner/prot of the NFS mount anchor in VMS itself?
DIR only reads the INDEXFILE.SYS, where /DATE and /SIZE have to READ the file HEADER, and /OWN and /PROT have to use info from the header to tranlate it using the RIGHTSLIST.
And for a (directory-) file with 3000 entries, that DOES make a difference.
Although I would not expect THAT big.

Still, I am curious about the amount caused by the extra file access, and the amount caused by NFS.

fwiw,

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

Are those files create from VMS and later reported on by VMS? When you did the Solaris comparision, did did you have it report on its 'own files' or on those VMS file?

How is the performance if you report on files created by a Unix box from the VMS system?

I suspect the /ADF option plays a significant roles. It forces the read of a 'helper' file for each file. This helper file holds the VMS file attributes which Unix does NOT have, for example something as 'simple' as a file creation date.

Unix has only a handfull (11 ? see fstat()) file attributes which are quickly retrieved from the directory (inode). VMS has many more attributes, but they are slow to retreive using an extra IO or two from the file headers in INDEXF.SYS on a VMS box, or from the .$ADF$file files on an NFS server.

Still 20 minutes seems excessive even if an extra file IO per file is needed

fwiw,
Hein.

[lxworks]

the files are contributed from various platforms, anyway, no other client show such a slow performance. for the acp-parameters, I think, the "mounter" and the "lister" have enough quota to satisfy the needs. maybe someone can add some hints...

WSdef: 131072
WSquo: 262144
WSextent: 393216

I'll next follow the adf issue, but I actually don't know, if its needed by anyone. as it is really productive, I have to take care :-(

[Wim Van den Wyngaert]

On VMS, also try to see what is consumed by the NFS client process (during the 20 minutes, IO's ? CPU ? PF's ?). show proc/con/id= will show the state. In wait states ?

You can try TCPTRACE to see who is delaying the communication.

Your quotas are fine. 20 minutes means about 3 files per sec. That is terribly slow.

Wim

[Volker Halle]

Alex,

tracing this is easy with tcpdump:

$ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS
$ tcpdump host mynetapp and port nfs

Between 2 VMS systems, the first plain DIR command will exchange lots of 'lookup' NFS packets. When invoking the plain DIR command the second time, all it does is exchange a couple of 'readdir' messages. And that's much faster. For 2000 files, elapsed time drops from 1 minutes to less than 1 second on successive attempts.

The full DIR command always exchanges lots of 'getattr' NFS packets. When invoked a 2nd or 3rd time (without remounting the NFS device), it still is faster (about twice as fast). Elapsed time drops from 1 minute to about 30 seconds for successive attempts.

Tested with a directroy of 2107 files between Alpha with TCPIP V5.5 (NFS server) and rx2600 with TCPIP V5.5 (NFS client)

As some caching is certainly involved here (NFS server ? client ? file system ?), it makes predicting the performance a little bit hard.

Volker.

[lxworks]

I listed all environment data in my first message. the issue is the difference BETWEEN the NFS client on OpenVMS and the NFS client on other clients.

[Volker Halle]

Alex,

if you are interested in isolating the problem, you need to compare the data between the 'good' and the 'bad' performance case.

Comparing the tcpdump data, which can be easily collected on the VMS system - as I've shown - would be a first step.

An easily spottable difference may be in the no. of messages exchanged or in their timing/sequence.

As with all communication problems, you need a systematic approach to try to pin down the problem.

With the VMS to VMS case that I've tested, there is about a factor of 100 between the time for a subsequent DIR and a DIR/SIZ/...

Volker.

[lxworks]

for the tcpdump: I already did a tcpdump of one listing (with/without) yesterday, even on both platforms (NetApp & OpenVMS), the NetApp dump went to NetApp, but for the OpenVMS Call I wanted to wait for some opinions here.

As I am not able to read this data, I'll open a call at HP now, thanks to all who contributed their ideas.

brgds
alex

[Wim Van den Wyngaert]

You could try a remount with /cache_timeout=(dir:01:00,attr=1:00)

It seems that if changes are taking place the directory is reread every 30 secs. And file attributes remain in the cache for 15 secs. So, after 20 min you start again from scratch.

Wim

[lxworks]

I changed these values, too. no change. as it is very fast when doing this listing on a HPUX as NFS server I suspect this special OpenVMS/NetApp Connection as cause.