Re: pconn's don't use MemPools ?

On 19 Sep 2000, at 11:13, Henrik Nordstrom <hno@hem.passagen.se> wrote:

> Andres Kroonmaa wrote:
>
> > I'm wondering what makes the basis for decision on when to use memPools
> > and when not to.
>
> In theory pools should be user wherever a fixed size structure is
> managed. However not all of the old baggage has been converted, and
> sometimes people are a bit too lazy to use the pools construct.

 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?

> > I've also noticed that use on Pools is quite inconsistent.
>
> Are you referring to the two methods available (direct usage, or via
> Mem.c)?

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

> > It seems to me that pconn.c uses very small allocations, does it
> > matter if it is used with pools?
>
> For the memory usage statistics it matters.

 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.
 Other than that, no problem with me.

> > on the same note, can someone explain me, where and why on earth
> > does squid malloc ram in sizes of 120-600KB in one shot?
>
> Good question. Not aware of any such allocations. Can you please make a
> trace of where it happens? (can be done by attaching a debugger and
> setting a conditional breakpoint in xmalloc or whatever the statistics
> enabled version is called)

 they happen quite rarely. I have only production caches to try to catch
 those, and I'd really not run them under breakpoint.
 Can we modify xmalloc to print a stacktrace when alloc size is over
 some limit?

 sample:

Memory allocation statistics
        16 = 16471227
        32 = 26261376
        48 = 9736109
        64 = 14493342
        80 = 2912897
        96 = 1402087
        112 = 860626
        128 = 1705338
        144 = 1108551
        160 = 164544
        176 = 106177
        ....
        16336 = 36
        16352 = 31
        16368 = 34
        16384 = 318340
        32000 = 1
        32704 = 2
        32768 = 1471
        64000 = 1
        65472 = 2
        80000 = 1
        120000 = 1
        180000 = 1
        270000 = 1
        405008 = 1
        607504 = 1
        911248 = 1

 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.
 But I've certainly missed lot of others.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Tue Sep 19 2000 - 05:06:34 MDT