Re: [squid-users] high memory usage (squid 3.2.0)

From: Marcello Romani <mromani_at_ottotecnica.com>
Date: Wed, 10 Apr 2013 15:00:53 +0200

Il 10/04/2013 14:29, Marcello Romani ha scritto:
> Il 10/04/2013 13:59, Mr Dash Four ha scritto:
>>
>>
>> Marcello Romani wrote:
>>> Il 09/04/2013 19:33, Mr Dash Four ha scritto:
>>> > [snip]
>>>> if the maximum_object_size_in_memory is reduced,
>>>> then I suppose squid's memory footprint will have to go down too, which
>>>> makes the cache_mem option a bit useless.
>>>
>>> I think will just store more objects in RAM.
>> I am sorry, but I don't understand that logic.
>>
>> If I set cache_mem (which is supposed to be the limit of ram squid is
>> going to use for caching), then the maximum_object_size_in_memory should
>> be irrelevant. The *number* of objects to be placed in memory should
>> depend on cache_mem, not the other way around.
>
> You're wrong.
> Each object that squid puts into cache_mem can have a different size.
> Thus the number of objects stored in cache_mem will vary over time
> depending on the traffic and selection algorithms.
>
>>
>> What currently seems to happen is that cache_mem is completely ignored
>> and squid is trying to shove up as many objects into my ram as possible,
>> to the point where nothing else on that machine is able to function
>> nominally. This is like putting cart in front of the horse - ridiculous!
>
> As stated elsewhere, previous versions of squid had memory leaks. That
> doesn't mean squid is _designed_ to put as many objects in ram as possible.
>
> Also, the cache_mem value must not be confused with a hard limit on
> total squid memory usage (which AFAIK cannot be set). For example
> there's also the memory used to manage the on-disk cache (10MB per GB
> IIRC - google it for a reliable answer).
>

As an addition to my previous comment, please read this comment in
squid.conf (3.1.6 FWIW):

# TAG: store_avg_object_size (kbytes)
# Average object size, used to estimate number of objects your
# cache can hold.

-- 
Marcello Romani
Received on Wed Apr 10 2013 - 13:00:57 MDT

This archive was generated by hypermail 2.2.0 : Wed Apr 10 2013 - 12:00:05 MDT