[OpenAFS] poor out of cache behavior on writing

Sven Oehme oehmes@de.ibm.com
Tue, 18 Feb 2003 12:31:22 +0100


This is a multipart message in MIME format.
--=_alternative 003F4A3FC1256CD1_=
Content-Type: text/plain; charset="US-ASCII"

hy , 

i have seen increasing the memcache size >50 mb on a Linux Server with 512 
mb that afs is crashing .

Sven





Paul Blackburn <mpb@est.ibm.com>
Sent by: openafs-info-admin@openafs.org
02/18/2003 10:06 AM
 
        To:     Edward Moy <emoy@apple.com>
        cc:     openafs-info@openafs.org
        Subject:        Re: [OpenAFS] poor out of cache behavior on 
writing

 

Edward Moy wrote:

>
> Yes, it is true that fast read performance should be a higher 
> priority. But if I want to read a 1 GB file from AFS, I have to write 
> it there in the first place.
>
> Look at the times to read that same 1 GB file:
>
> nfs 0.050u 18.050s 2:25.59 12.4%
> afs 0.5GB cache 0.030u 10.300s 2:29.26 6.9%
> afs 2GB cache 0.030u 11.250s 2:32.67 7.3%
>
> Within the normal fluctuations in the network itself, AFS is very 
> close to raw NFA, for first-time reading. But also note that even when 
> the cache is smaller than the file, one does not see the poor behavior 
> exhibited in the write case. 

Hi Edward,

I think you have succintly made the point that you need to size
your AFS cache appropriately for your workload.

If you plan on working with 1gb files often and writing 1gb files
into /afs/@cell/$whatever/ then you better configure a big enough AFS 
cache.

I think that "cache thrashing" is similar to "page thrashing"
in virtual memory operating systems. It is a situation that
occurs when there is not enough resource allocated (eg cache too small)
for the workload applied to it.

Remember also that with AFS, you have a choice of disk cache
or RAM cache. So if you have enough installed RAM, you
will see faster access using AFS RAM cache (than using disk cache).

>
>
> It takes 2 1/2 minutes to read the file, and 4 minutes to write it 
> when there is enough cache. But as a user, when that goes up to 10 
> minutes, and uses 80% of the processor, my first reaction would be 
> that something is wrong.
>
> From other comments I've seen, it appears that this is "expected" 
> (though hopefully not desirable) behavior. I just wanted to point out 
> that there is room for improvement in this area. 

You are absolutely right to point this out.
If there is something "not working right" with AFS write function
then this is a good place to discuss it and propose solutions.
--
cheers
paul http://acm.org/~mpb


_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info


--=_alternative 003F4A3FC1256CD1_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">hy , </font>
<br>
<br><font size=2 face="sans-serif">i have seen increasing the memcache
size &gt;50 mb on a Linux Server with 512 mb that afs is crashing .</font>
<br>
<br><font size=2 face="sans-serif">Sven</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Paul Blackburn &lt;mpb@est.ibm.com&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: openafs-info-admin@openafs.org</font>
<p><font size=1 face="sans-serif">02/18/2003 10:06 AM</font>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To:
&nbsp; &nbsp; &nbsp; &nbsp;Edward Moy &lt;emoy@apple.com&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;openafs-info@openafs.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;Re: [OpenAFS] poor out of cache behavior
on writing</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2><tt>Edward Moy wrote:<br>
<br>
&gt;<br>
&gt; Yes, it is true that fast read performance should be a higher <br>
&gt; priority. But if I want to read a 1 GB file from AFS, I have to write
<br>
&gt; it there in the first place.<br>
&gt;<br>
&gt; Look at the times to read that same 1 GB file:<br>
&gt;<br>
&gt; nfs 0.050u 18.050s 2:25.59 12.4%<br>
&gt; afs 0.5GB cache 0.030u 10.300s 2:29.26 6.9%<br>
&gt; afs 2GB cache 0.030u 11.250s 2:32.67 7.3%<br>
&gt;<br>
&gt; Within the normal fluctuations in the network itself, AFS is very
<br>
&gt; close to raw NFA, for first-time reading. But also note that even
when <br>
&gt; the cache is smaller than the file, one does not see the poor behavior
<br>
&gt; exhibited in the write case. <br>
<br>
Hi Edward,<br>
<br>
I think you have succintly made the point that you need to size<br>
your AFS cache appropriately for your workload.<br>
<br>
If you plan on working with 1gb files often and writing 1gb files<br>
into /afs/@cell/$whatever/ then you better configure a big enough AFS cache.<br>
<br>
I think that &quot;cache thrashing&quot; is similar to &quot;page thrashing&quot;<br>
in virtual memory operating systems. It is a situation that<br>
occurs when there is not enough resource allocated (eg cache too small)<br>
for the workload applied to it.<br>
<br>
Remember also that with AFS, you have a choice of disk cache<br>
or RAM cache. So if you have enough installed RAM, you<br>
will see faster access using AFS RAM cache (than using disk cache).<br>
<br>
&gt;<br>
&gt;<br>
&gt; It takes 2 1/2 minutes to read the file, and 4 minutes to write it
<br>
&gt; when there is enough cache. But as a user, when that goes up to 10
<br>
&gt; minutes, and uses 80% of the processor, my first reaction would be
<br>
&gt; that something is wrong.<br>
&gt;<br>
&gt; From other comments I've seen, it appears that this is &quot;expected&quot;
<br>
&gt; (though hopefully not desirable) behavior. I just wanted to point
out <br>
&gt; that there is room for improvement in this area. <br>
<br>
You are absolutely right to point this out.<br>
If there is something &quot;not working right&quot; with AFS write function<br>
then this is a good place to discuss it and propose solutions.<br>
--<br>
cheers<br>
paul http://acm.org/~mpb<br>
<br>
<br>
_______________________________________________<br>
OpenAFS-info mailing list<br>
OpenAFS-info@openafs.org<br>
https://lists.openafs.org/mailman/listinfo/openafs-info<br>
</tt></font>
<br>
--=_alternative 003F4A3FC1256CD1_=--