File attribute retrieval

[Matt Wardle]

One of our NFS server (11.11, nfs v3) is showing a getattr of 76% (nfsstat -s). According to various docs it shouldn't be more than 60%, causing overheads due to continual checking of file attributes.

So I thought I'd have a go at configuring some of the (11.11) clients with actimeo options on some of the more static filesystems to reduce this.

However, "nfs performance tuning for hp-ux" by Dave Olker, on p90 says: File attribute retrieval on 11.11 is supplied in every reply.

So does that mean whatever I try with the actimeo caching options, I won't see any improvement?

Or I am grasping the wrong end of the stick?

Thanks,

Matt.

[Dave Olker · Accepted solution]

Hi Matt,

What document have you read that says an NFS server shouldn't be serving more than 60% GETATTR calls? I've never heard of this. The server simply services the requests it is sent by the clients. It has no control over the mix of requests the clients send.

The actual mix of NFS requests sent by a client are dependent on so many things, most of which are out of your control. Among them are: OS version, patch level, library versions, application design, NFS mount options, etc.

Some NFS implementations of the NFS client do a better job than others of using the post-operation attributes included in NFS V3 reply packets. Some implementations completely ignore the post-op attributes. Of those that do use the post-op attributes, there are still dozes of scenarios where they will decide their cached attributes are either stale or need to be updated with a check of the server's copy of the attributes. There are also many places in the client kernel code where explicit calls to GETATTR are made, and many of these result in over-the-wire GETATTR calls regardless of the client's cache state.

In any case, you can certainly try playing with the attribute cache mount options. I'll be surprised if these make any real significant difference in the number of GETATTR calls the server performs.

Is there a specific reason why you're looking at the NFS server-side call statistics in the first place? Unless this is just an "academic curiosity" type situation, I assume there is an underlying reason for monitoring the server's statistics?

Again, I'd be curious about the documents that talk about a 60% GEATTR mix. Are those HP documents?

Thanks,

Dave

[Matt Wardle]

Hi Dave.

Thanks for the reply.

The documents I were reading were:

http://docs.hp.com/en/5991-1811/ch08s04.html

about half way down the page it says:

"If the value of getattr displayed by nfsstat -s is greater than 60%, one or more clients have either turned off attribute caching (with the noac mount option) or set the caching timeout values too low.

Increase the attribute caching timeouts on the clients that have them set below the default values. See "Changing the Default Mount Options" ."

Also no. 11 on this Technical knowledge base document:

http://www5.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000080024249

So it lead me to thinking that 76% for just getting the attributes of the file was too high. But I suppose if you get attributes with every call, that would make sense.

I was in the course of looking into why we were getting "nfs server not responding" messages on some of our clients. With users sitting with frozen workstations for up to a couple of minutes.

A couple of the clients still had the timeo option on, which I removed and it is better since then.

Cheers,

Matt.