[squid-users] Squid 3.5.7, cache_swap_high, bug or not bug ?

[Amos Jeffries]

On 25/08/2015 1:10 a.m., FredT wrote:
> Amos,
> 
> Uploading the patched squid took time to be agreed by the client, sorry but
> the server is in production and we cannot take the risk to see if the action
> will crash or not the squid, i don't want to lose this client...
> 
> If you fix in the next release the cache_swap_low/high taking care the
> Percent Used and the Filemap, it would be a good solution at the moment 
> 
> Keep us posted...
> 
> Bye Fred
> 

I've spoken the change over with Alex who knows the overall store
behaviours a bit better than we decided to remove the over-100% part of
the patch for now. At least until someone can test it properly. That
would be the fix for bug 2448, with test-case provided in there if
anyone is keen to take it on.


Instead I have slightly increased the rate to a full 200 objects/sec for
easier calculations and just let the multiplier for the removal rate
increase indefinitely.

What this means in practice is the low-water mark is still the signal
for eviction to begin (or stop if utilization drops under that) but the
relative position of the high-water mark to it determines the agressiveness.

What "aggressive" means is a linear scale of evictions/sec. The 'gap'
percentage between the two marks represents 200 objects to be evicted,
and each multiple of that gap above low-water is another 200 objects
removed from the cache that second.
 If high-water is set equal or lower than low-water mark the rate is a
flat 220 objects per second evicted.


So in a way we have the squid.conf controlled agressiveness. With the
defaut 90%/95% watermarks Squid will be attempting to remove 420
objects/sec by the time it reached 100% cache_dir capacity. Which should
be plenty for just about every installation.
But if you were say, needing Squid to evict 800 objects/sec you could
set them to 92% and 94%. Closer for smaller 2% gap, and 200 x4 of that
gap between low-water and 100% capacity.

But also keep in mind thats purges/sec. The HIT and REFRESH requests
serviced do not count here at all. So the rate needed is almost always
much lower than the per-second equivalent of request per minute rate
shown in mgr:info report.

There is also a feature request to turn these watermarks from whole
percentages to taking decimals. Which would make them even nicer for
this. But that is a much bigger change for later. If anyone wants to
sponsor that work I'm available.

Amos