reply cache

reply cache

[Jordi Prats]

Hi all,
According to the file fs/nfsd/nfscache.c (line 30 on 2.6.23), reply 
cache is fixed size. Why is this a fixed size cache? Shouldn't be 
relative to the number of nfsd threads? I've a server with this statistics:

rc 0 959398 336415498

By what I've been researching this means: 0 hits, 959398 misses (I 
supose that means something like "recently deleted") and 336415498 not 
in cache (and never has been). Is that right?

Modifying the CACHESIZE to a bigger size do you think it could enhance 
NFS performance by getting some hits on the reply cache?

Thanks!
Jordi

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: reply cache

[Chuck Lever]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

Jordi Prats wrote:
> According to the file fs/nfsd/nfscache.c (line 30 on 2.6.23), reply 
> cache is fixed size. Why is this a fixed size cache? Shouldn't be 
> relative to the number of nfsd threads? I've a server with this statistics:
> 
> rc 0 959398 336415498
> 
> By what I've been researching this means: 0 hits, 959398 misses (I 
> supose that means something like "recently deleted") and 336415498 not 
> in cache (and never has been). Is that right?

A DRC hit implies the client is retransmitting.  Not having any hits is 
a good thing -- it means your server is able to handle all your clients 
without much sweat.

> Modifying the CACHESIZE to a bigger size do you think it could enhance 
> NFS performance by getting some hits on the reply cache?

The server's DRC is not a performance feature.  It's a way for the 
server to detect replayed requests from the client.  In a perfect world, 
servers wouldn't even have one.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 259 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: reply cache

[Jordi Prats]

Thank you!

I miss understood the reply cache, I was thinking it as a way it caches 
the answer to a question like "which are the attributes of that file?"

Now I'm happy with my zero hits ;)

Jordi

Chuck Lever wrote:
> Jordi Prats wrote:
>> According to the file fs/nfsd/nfscache.c (line 30 on 2.6.23), reply 
>> cache is fixed size. Why is this a fixed size cache? Shouldn't be 
>> relative to the number of nfsd threads? I've a server with this 
>> statistics:
>>
>> rc 0 959398 336415498
>>
>> By what I've been researching this means: 0 hits, 959398 misses (I 
>> supose that means something like "recently deleted") and 336415498 not 
>> in cache (and never has been). Is that right?
> 
> A DRC hit implies the client is retransmitting.  Not having any hits is 
> a good thing -- it means your server is able to handle all your clients 
> without much sweat.
> 
>> Modifying the CACHESIZE to a bigger size do you think it could enhance 
>> NFS performance by getting some hits on the reply cache?
> 
> The server's DRC is not a performance feature.  It's a way for the 
> server to detect replayed requests from the client.  In a perfect world, 
> servers wouldn't even have one.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: reply cache

[Talpey, Thomas]

At 12:53 PM 10/15/2007, Jordi Prats wrote:
>Hi all,
>According to the file fs/nfsd/nfscache.c (line 30 on 2.6.23), reply 
>cache is fixed size. Why is this a fixed size cache? Shouldn't be 
>relative to the number of nfsd threads? I've a server with this statistics:
>
>rc 0 959398 336415498
>
>By what I've been researching this means: 0 hits, 959398 misses (I 
>supose that means something like "recently deleted") and 336415498 not 
>in cache (and never has been). Is that right?

No, the large number is NOCACHE, which means the operation does not
require caching at all (it's an idempotent operation). The smaller number
is either a new operation that does require caching, or a retransmit that
didn't hit.

>Modifying the CACHESIZE to a bigger size do you think it could enhance 
>NFS performance by getting some hits on the reply cache?

A bigger cache will only waste memory in your case. If you had a very
large miss count, then it might be warranted, but in any case it is not
going to help performance unless you're seeing a large number of client
retransmits. And even then, the fix is not a bigger cache.

Tom.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs