Comment 1 for bug 1465625

We hit what we suspect may be an instance of this problem in Azure's west US last night. Squid got OOM killed and it caused the unit to serve some 503s for about a minute. Looking at the unit's config, it actually seems pretty reasonable, Squid has a 2164M in memory cache on a 7G RAM unit and after about a day of serving traffic is sitting right around 33% of RAM, 2515M in memory. I'm not sure what circumstances would lead to an OOM unless another process were talking up substantial amounts of memory while Squid tried to allocate a big chunk, but both landscape and juju are known to have spiky memory usage and I can certainly imagine a situation where a confluence of spikes in memory usage by other processes leads to an OOM.

Maybe we should drop the initial allocation of memory for Squid's in memory cache down to to a third from half? That's still a VERY substantial cache and considering the hit rate for busy regions hovers around 100%, I don't think we need to optimize quite so heavily for in memory caching.