8:21 p.m.
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
12:32 a.m.
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)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:10 a.m.
"Brett @Google" <brett.maxfield(a)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 Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°37'09,95"N
10°08'02,42"E
8:05 a.m.
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...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:58 a.m.
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 ?
10:20 a.m.
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 ?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:36 a.m.
--On Sunday, November 22, 2009 02:21:41 PM +1000 "Brett @Google"
<brett.maxfield(a)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
--
Bill MacAllister, System Software Programmer
Unix Systems Group, Stanford University
10:01 a.m.
--On Monday, November 23, 2009 9:36 AM -0800 Bill MacAllister
<whm(a)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
4940
days inactive
4942
days old
openldap-software@openldap.org
7 comments
6 participants
participants (6)
-
Bill MacAllister -
Brett ＠Google -
Brett Maxfield
-
Dieter Kluenter -
Howard Chu -
Quanah Gibson-Mount