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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
