Garbage Collection in Proxy 4.0

There seems to be a lot of confusion regarding the exact process / logic of Garbage Collection in Proxy 4.0. People who rely on cachegc seem to be particularly affected by this. So i thought i'll just note down whatever i could make out through a quick code read. If you look into a server.xml, you typically find something like this:

<PARTITION  partitionname="part1" partitiondir="/tmp/ctest/proxy-server1/cache"
maxsize="10" minspace="5" enabled="true"/>
        <GC enabled="true" gchimargin="80" gclomargin="70"
gcleavefsfull="60" gcextramargin="30"/>

If you run cachegc without any arguments, you get this help message:

 Options to cachegc are : 
         -h : print this message
         -f : leave_fs_full_percent
         -u : gc_hi_margin_percent
         -l : gc_lo_margin_percent
         -e : extra_margin_percent
         -d : configuration directory (mandatory)

Let me begin by first explaining the important parameters involved.

maxsize (server.xml parameter)

This specifies the maximum size (in MB) of the cache partition.

minspace (server.xml parameter)

This parameter specifies the minimum space (in MB) that should be kept available in the cache partition.

Let's say we specify a minspace of X. Now the Garbage Collector runs, and notices that the current size of the cache partition is say, C. Now it calculates the currently available space by subtracting the current size, C, from the value of maxsize. Let that value be Y, and let's also assume that Y turns out to be greater than X. (Please note that "currently available" space is calculated by subtracting the current size from maxsize)

So the Garbage Collector decides to cleanup an amount of space R such that R = X - Y. But it's not over yet...

gcleavefsfull (Server.xml parameter as well as "-f" option to cachege)

This is a sort of "low water mark". One can specify a percentage through this parameter, which is applied to the current size. I mean, if the current size is 100 MB, and a gcleavefsfull of 70 is specified, then the "low water mark" is 70 MB.

Now continuing from the above step, the Garbage Collector has a value R which is the amount of size it wants to free up. Now it thinks like this: If i free up a space of R, will the resultant size (C - R) be lesser than the low water mark value?

If so, then more work is needed. Obviously R is too large. It first makes sure that the current size, C, is greater than the low water mark in the first place. Else, there is no question of freeing up any space. Once that's confirmed, the value of R is adjusted such that R = C - (low water mark).

Next step is to consider the implications of freeing up a space of R and how that will cope with the restrictions imposed by gchimargin.

gchimargin (Server.xml parameter and -u option to cachegc)

gc_hi_margin_percent specifies a percentage of maxsize beyond which the cache partition is not allowed to grow. So now if C - R happens to be beyond this limit, then the Garbage Collector decides that freeing up a space of R is not enough. At this point, the value of R is adjusted such that freeing up a space of R will bring down the current size to gclomargin which again is a server.xml parameter, "-l" option to cachegc, and is applied as a percentage of maxsize.

And that brings us to the final point in this maze: gcextramargin. (Server.xml parameter and "-e" option to cachegc)

Now if the earlier condition was wrong: ie. C - R is within gc_hi_margin_percent. So there is no need to adjust R to bring down the current size to gclomargin. But here the Garbage Collector does one more check: Is the current size, C, already greater than maxsize? If so, increase R (even though R is enough to bring down C to less than gchimargin) by adding an "extra margin" to it.

The extra margin is calculated as a percentage of the current size, and gets added to R.

So now the Garbage Collector is left with a value R which is the amount of space it can free up.

Phew...it's evening, i'm tired and it's time for some Brandy!

Comments:

Thanks for help, Keep up the good work.

Posted by Mp3 player on shtator 25, 2007 at 08:19 PD PDT #

Interesting article!
Thanks

Posted by Grawerowanie laserowe on nëntor 21, 2007 at 07:32 PD PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

user13334066

Search

Archives
« korrik 2014
DieHënMarMërEnjPreSht
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today