Re: better malloc strategies?

[Howard Chu <hyc@symas.com>]

Howard Chu wrote:
> Running some other benchmarks today I saw something rather odd - after 
> slapd had been running for a while, and the entry cache had been 
> churned around, slapd would sit at 100% CPU on a new incoming 
> connection for several minutes, inside the malloc() function, before 
> eventually progressing. At a guess, memory has become badly fragmented 
> due to so many entries being added and freed from the entry cache, and 
> allocating small blocks (only 18 bytes, for the connection peername in 
> this case) gets to be a real problem.
>
> I've played with libhoard in the past and gotten mixed results.  I 
> wonder if this is just a particularly bad version of glibc, or 
> something we really have to worry about.  (RHEL4 based system, kernel 
> 2.6.9-22, glibc 2.3.4, AMD64 machine, 6GB of RAM free out of 32GB at 
> the time.)
As a first cut, I plan to recycle Entry and Attribute structures on our 
own free lists. That ought to reduce some of the general malloc 
contention, as well as some degree of the churn. Will be testing this in 
the next few days.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/