RE: Squid-2.5

On 2 Oct 2001, at 17:34, Chemolli Francesco (USI) <ChemolliF@GruppoCredit.it> wrote:

> > Hi fellow Squid hackers.
> >
> > I propose we branch Squid-2.5 real soon now and make a official
> > PRE-STABLE release, or is there any known issues that must be
> > addressed first?

 I've seen nothing major.

> Memory leaks, but I think nothing functionality-wise.
..
> Well, I have stretches up to 10M hits until I have to restart for the
> aforementioned leaks (and unfortunately the occasional leaked helper process
> :().

 This issue is very confusing. I'm here almost 100% confident, that
 there are no leaks in squid. Of course, it also depends on how squid
 is compiled and abit on how its used.
 I have 2 squid's on HEAD, neither has shown any signs of leaks of
 any kind. Both have done (as of now) over 500GB cumulative mempool
 allocs and both are well beyond 10M reqs serviced.
 There is a slight difference to HEAD - I use chunked_mempools here.
 but this hasn't changed anything in regards to memory leaks.

 I think that many so-called memory leaks are misnamed. I may be
 wrong and then let me be corrected. Why not go through this.

 From my experience, there are several things that can cause false
 sense of memory leaks:
 - stupid OS memory allocator. Solaris is notorious for that. It
   allocs memory, but never frees. Process at any time is as large
   as its peak memory usage has ever been.
   Fix: --enable-dlmalloc
   I'm not sure how is default Linux malloc tuned, but I'd not be
   surprised if it has similar behaviour.

 - idle pools limit. Default is "none", which means 2G. mempools do
   not return memory to OS. Heavy fragmentation occurs over time.
   Fix: memory_pools_limit=8M. Going much up doesn't really help.

 - increased memory footprint of Squid. I've seen this when I compiled
   in heap-replacement. Not sure how its now, but when I tried it, it
   consumed about 2-4 pointers per storeentry in addition. Together
   with malloc roundups this was quite notable. One of my 2.3 squids
   is experiencing this. heap memory overhead is not accounted for
   as it doesn't use mempools.

 I can't say that there isn't any leaks. It just doesn't show up
 for me. If we know where leaks are, then we can address them.
 As I understand, noone really knows if and where they are.

 We should really first try determine conditions when leaks occur.
 In this group and together with bug reporters.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Tue Oct 02 2001 - 10:14:08 MDT