[Date Prev][Date Next]
better malloc strategies?
- To: openldap-devel@OpenLDAP.org
- Subject: better malloc strategies?
- From: Howard Chu <firstname.lastname@example.org>
- Date: Tue, 11 Jul 2006 14:06:00 -0700
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060613 SeaMonkey/1.5a
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.)
-- 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/