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.