On Fri, Dec 13, 2013 at 3:32 PM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 12/12/2013 06:50 PM, Nathan Hoad wrote: > >> This leads me to believe that the objects that are consuming all of >> the memory are genuinely using that memory, and are freed on shutdown. > > This hypothesis is relatively easy to test, especially if you can > reproduce the high memory usage in a lab (or if you can control live > load on a given Squid instance): Load Squid for a while. Then, instead > of stopping Squid, let it sit for a few minutes without traffic so that > there are no HTTP transactions waiting for timeouts and such. Then again > load Squid with traffic for a few minutes. Repeat a few times while > measuring memory usage. > > If, after a few iterations, the base of the memory usage humps stay > about the same, then your theory is probably correct. If the base of the > humps keep climbing up, there is an effective leak, even if all that > accumulated memory is freed by Squid during a proper shutdown. Controlling live load on the given Squid instance isn't possible (an office of ~30 people), and so far all attempts to reproduce the issue in a clean environment have been unsuccessful - this weekend though I am attempting some heavier tests by running the past week's access.log through a Squid instance in controlled environment. I will see if this reproduces the issue I've been seeing and if so, will do what you've described above. > > The next step would depend on the above outcome. Either we will need to > compare memory usage of v3.2 and v3.3 (to identify the objects or areas > that started consuming more RAM) OR we can help you find the v3.3 leak > (e.g., using valgrind or log analysis). > > > HTH, > > Alex. > Also, to answer Amos' question without another email, this is an upgrade from 3.2.13 to 3.3.11, although the issue did present itself in 3.3.10 as well.
