Hello,
I was wondering of anybody has used much of tcmalloc (from google performance tools) and has any opinion they care to share with regards to performance of berkeleydb/openldap toolset ?
Seems about the same with as without for a simple slapadd, but i'd expect that wins would be more around a highly loaded server, not the initial load process?
(investigations continue however, server loading is next)
Cheers Brett
Brett @Google wrote:
Hello,
I was wondering of anybody has used much of tcmalloc (from google performance tools) and has any opinion they care to share with regards to performance of berkeleydb/openldap toolset ?
Yes, tcmalloc is great.
http://highlandsun.com/hyc/malloc/
Old news...
Seems about the same with as without for a simple slapadd, but i'd expect that wins would be more around a highly loaded server, not the initial load process?
slapadd re-uses most of its memory, and therefore doesn't make excessive calls to malloc.
(investigations continue however, server loading is next)
"Brett @Google" brett.maxfield@gmail.com writes:
Hello,
I was wondering of anybody has used much of tcmalloc (from google performance tools) and has any opinion they care to share with regards to performance of berkeleydb/openldap toolset ?
I included tcmalloc into my build system. While I didn't measure a large gain in performance, memory allocation is much cleaner now. There are some side efects though, if SASL library is not recompiled with tcmalloc, but this can be solved by not building openldap with -ltcmalloc but load libtcmalloc by an ld_preload environment variable. [...]
-Dieter
Dieter Kluenter wrote:
"Brett @Google"brett.maxfield@gmail.com writes:
Hello,
I was wondering of anybody has used much of tcmalloc (from google performance tools) and has any opinion they care to share with regards to performance of berkeleydb/openldap toolset ?
I included tcmalloc into my build system. While I didn't measure a large gain in performance, memory allocation is much cleaner now.
Right. We've already minimized our actual use of malloc enough that it's not a performance issue; at this point it's mainly about heap fragmentation.
There are some side efects though, if SASL library is not recompiled with tcmalloc, but this can be solved by not building openldap with -ltcmalloc but load libtcmalloc by an ld_preload environment variable. [...]
I only use LD_PRELOAD. Simplifies things when I want to test with other malloc libraries/leak checkers/debuggers/etc...
Hmm.. Could not get tcmalloc to compile at all on sparc, using either sun compiler or the canned gcc in /usr/sfw. Aparently it uses some asm, not ported to sparc.
I was wondering of anybody has used much of tcmalloc (from google performance tools) and has any opinion they care to share with regards to performance of berkeleydb/openldap toolset ?
Brett Maxfield wrote:
Hmm.. Could not get tcmalloc to compile at all on sparc, using either sun compiler or the canned gcc in /usr/sfw. Aparently it uses some asm, not ported to sparc.
The README says only x86 and x86-64 are well supported. PPC support was added more recently. Nothing for sparc.
The README also points to our results with OpenLDAP...
If you're using Solaris/sparc you might as well just use libumem which they already provide.
I was wondering of anybody has used much of tcmalloc (from google performance tools) and has any opinion they care to share with regards to performance of berkeleydb/openldap toolset ?
--On Sunday, November 22, 2009 02:21:41 PM +1000 "Brett @Google" brett.maxfield@gmail.com wrote:
Hello,
I was wondering of anybody has used much of tcmalloc (from google performance tools) and has any opinion they care to share with regards to performance of berkeleydb/openldap toolset ?
Seems about the same with as without for a simple slapadd, but i'd expect that wins would be more around a highly loaded server, not the initial load process?
(investigations continue however, server loading is next)
Cheers Brett
The only authenticated binds to our directory service that we support are GSSAPI binds. On Linux, Cyrus SASL/malloc leak memory bad enough that without either hoard or tcmalloc OpenLDAP is unusable.
Bill
--On Monday, November 23, 2009 9:36 AM -0800 Bill MacAllister whm@stanford.edu wrote:
The only authenticated binds to our directory service that we support are GSSAPI binds. On Linux, Cyrus SASL/malloc leak memory bad enough that without either hoard or tcmalloc OpenLDAP is unusable.
This has nothing to do specifically with Cyrus SASL/GSSAPI, and everything to do with how glibc mallocs memory. I can make any linux system fairly unusable running OpenLDAP with a good sized database and a lot of read activity. Including Stanford's database. ;)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org
-
Bill MacAllister -
Brett ＠Google -
Brett Maxfield
-
Dieter Kluenter -
Howard Chu -
Quanah Gibson-Mount