Re: pconn's don't use MemPools ?

Andres Kroonmaa wrote:

> hmm, what is the goal of using pools for every struct? The more pools
> are used, the more overhead they introduce. When some structs do not
> contribute to overall ram usage, is it useful to impose load on pools?

When allocations does not contribute to over all ram usage, the overall
overhead of using a memory pool for that struct is also negligable.

The benefit is that we know how much memory is used for that kind of
struct, and can easily detect if there is any memory leaks (even if
slow) in that kind of allocation.

> well, i didn't know there are 2 methods. I meant xmalloc vs. memAllocate

There is also memPoolAlloc.

memAllocate is the highest level call

below that is memPoolAlloc

and at the bottom is xcalloc/xmalloc and friends.

I prefer the memPoolAlloc level.

> I'm worried that if we put all allocations into pools, we'd have
> very long listing eventually that is hard to read, and quite some
> overhead for mallocs.

The overhead of memory pools is less than malloc(), unless you count the
slightly increased memory usage from the pool counters (a few bytes) and
the eventual idle allocations.

> they happen quite rarely. I have only production caches to try to
> catch those, and I'd really not run them under breakpoint.

Understandable.

> Can we modify xmalloc to print a stacktrace when alloc size is over
> some limit?

If stacktraces are supported on your platform yes. Squid has code for
printing stacktraces on Solaris and Linux.

> I've seen max tracked allocs also. not sure how large they were.
> The only 2 cases I could see, are URL string strdups (I guess not)
> and realloc in client_side.c when handling large requests.

URL's is not the case. Squid puts a relatively small upper limit on ULR
lengths.

You are probably right about the others. There are for examples some
issues in Squid-2.3 and earlier where certain classes of server replies
can chew up a LOT of memory in a big realloc..
http://squid.sourceforge.net/hno/patch-2.3.html

/Henrik
Received on Wed Sep 20 2000 - 16:07:39 MDT