Hi,
I am working on building and benchmarking OpenLDAP v2.4.16 for a large entries directory (actual test: 2 000 000 but final objective 10 000 000 users).
I use SLAMD to test authentication in order to evaluate what is the maximum number of authentication I can do on my server. So I try to do 5 authentications per 5ms during 5min.
My OpenLDAP 2.4.16 is install on the X86 two core 2.8Ghz server with 4Go of memory.
I set 3Go in cache of DB_Config and I have look a lot on how configure properly slapd.
Is it normal because I have reach system limits or can I change some parameter to optimize slapd performance?
Do some people have some figures about slapd performance with large entries directory on standard server?
Regards,
--- Thomas
--On Tuesday, April 21, 2009 6:24 PM +0200 "SAGNIMORTE Thomas (CAMPUS)" thomas.sagnimorte@oxylane-group.com wrote:
Hi,
I am working on building and benchmarking OpenLDAP v2.4.16 for a large entries directory (actual test: 2 000 000 but final objective 10 000 000 users).
I use SLAMD to test authentication in order to evaluate what is the maximum number of authentication I can do on my server. So I try to do 5 authentications per 5ms during 5min.
My OpenLDAP 2.4.16 is install on the X86 two core 2.8Ghz server with 4Go of memory.
I set 3Go in cache of DB_Config and I have look a lot on how configure properly slapd.
Is it normal because I have reach system limits or can I change some parameter to optimize slapd performance?
Do some people have some figures about slapd performance with large entries directory on standard server?
Where is the gdb backtrace of your segfault?
Which slapd backend are you using? bdb? hdb? something else? Did you properly tune the entry cache, idlcache, and dncache?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi,
I am using hdb backend.
Here is the gdb backtrace Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1140881728 (LWP 31250)] 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0
I set entry cache to 100000, idlcache to 10000 and dncache to 10000.
Regards,
Thomas
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Tuesday, April 21, 2009 6:58 PM To: SAGNIMORTE Thomas (CAMPUS); openldap-technical@openldap.org Subject: Re: Segfault during Auth Benchmark request
--On Tuesday, April 21, 2009 6:24 PM +0200 "SAGNIMORTE Thomas (CAMPUS)" thomas.sagnimorte@oxylane-group.com wrote:
Hi,
I am working on building and benchmarking OpenLDAP v2.4.16 for a large
entries directory (actual test: 2 000 000 but final objective 10 000 000 users).
I use SLAMD to test authentication in order to evaluate what is the maximum number of authentication I can do on my server. So I try to do
5 authentications per 5ms during 5min.
My OpenLDAP 2.4.16 is install on the X86 two core 2.8Ghz server with 4Go of memory.
I set 3Go in cache of DB_Config and I have look a lot on how configure
properly slapd.
Is it normal because I have reach system limits or can I change some parameter to optimize slapd performance?
Do some people have some figures about slapd performance with large entries directory on standard server?
Where is the gdb backtrace of your segfault?
Which slapd backend are you using? bdb? hdb? something else? Did you properly tune the entry cache, idlcache, and dncache?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Wednesday, April 22, 2009 10:52 AM +0200 "SAGNIMORTE Thomas (CAMPUS)" thomas.sagnimorte@oxylane-group.com wrote:
Hi,
I am using hdb backend.
Here is the gdb backtrace Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1140881728 (LWP 31250)] 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0
Hi Thomas,
This is not a backtrace, this just tells us where the segfault is being recorded from in gdb. What we need is the output of "thr apply all bt" inside gdb after this happens.
Thanks!
I set entry cache to 100000, idlcache to 10000 and dncache to 10000.
Seems reasonable.
--Quanah
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Tuesday, April 21, 2009 6:58 PM To: SAGNIMORTE Thomas (CAMPUS); openldap-technical@openldap.org Subject: Re: Segfault during Auth Benchmark request
--On Tuesday, April 21, 2009 6:24 PM +0200 "SAGNIMORTE Thomas (CAMPUS)" thomas.sagnimorte@oxylane-group.com wrote:
Hi,
I am working on building and benchmarking OpenLDAP v2.4.16 for a large
entries directory (actual test: 2 000 000 but final objective 10 000 000 users).
I use SLAMD to test authentication in order to evaluate what is the maximum number of authentication I can do on my server. So I try to do
5 authentications per 5ms during 5min.
My OpenLDAP 2.4.16 is install on the X86 two core 2.8Ghz server with 4Go of memory.
I set 3Go in cache of DB_Config and I have look a lot on how configure
properly slapd.
Is it normal because I have reach system limits or can I change some parameter to optimize slapd performance?
Do some people have some figures about slapd performance with large entries directory on standard server?
Where is the gdb backtrace of your segfault?
Which slapd backend are you using? bdb? hdb? something else? Did you properly tune the entry cache, idlcache, and dncache?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount ha scritto:
--On Wednesday, April 22, 2009 10:52 AM +0200 "SAGNIMORTE Thomas
I set entry cache to 100000, idlcache to 10000 and dncache to 10000.
Seems reasonable.
Since cachesize is 100K entries shouldn't idlcachesize be 300K ? (he's using hdb backend)
Ing. Luca Scamoni Responsabile Ricerca e Sviluppo
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni@sys-net.it -----------------------------------
--On Wednesday, April 22, 2009 7:23 PM +0200 Luca Scamoni luca.scamoni@sys-net.it wrote:
Quanah Gibson-Mount ha scritto:
--On Wednesday, April 22, 2009 10:52 AM +0200 "SAGNIMORTE Thomas
I set entry cache to 100000, idlcache to 10000 and dncache to 10000.
Seems reasonable.
Since cachesize is 100K entries shouldn't idlcachesize be 300K ? (he's using hdb backend)
Hm, I read that all as 10k. I'm guessing that a 100k cachesize and a 10k idlcachesize wouldn't be greatly productive, but I've often run my HDB backends with the same cachesize/idlcachesize without ill effect.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi,
Thanks for this information.
I look on backtrace with gdb and I have got this one. I hope this is what your except.
I join more detail, could you read it?
Thanks,
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1132489024 (LWP 11645)] 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 (gdb) backtrace full #0 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00000000004c7ea1 in hdb_cache_delete_cleanup () No symbol table info available. #2 0x00000000004c897c in hdb_cache_modrdn () No symbol table info available. #3 0x00000000004c9384 in hdb_cache_find_id () No symbol table info available. #4 0x00000000004cd193 in hdb_dn2entry () No symbol table info available. #5 0x00000000004a6513 in hdb_search () No symbol table info available. #6 0x00000000004314b6 in fe_op_search () No symbol table info available. #7 0x0000000000431c47 in do_search () No symbol table info available. #8 0x000000000042fa5b in connection_hangup () No symbol table info available. #9 0x0000000000430157 in connection_hangup () No symbol table info available. #10 0x000000000051f15a in ldap_pvt_thread_pool_submit () No symbol table info available. #11 0x0000003c024062e7 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x0000003c018ce3bd in clone () from /lib64/libc.so.6 No symbol table info available.
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Wednesday, April 22, 2009 7:25 PM To: Luca Scamoni Cc: SAGNIMORTE Thomas (CAMPUS); openldap-technical@openldap.org Subject: Re: Segfault during Auth Benchmark request
--On Wednesday, April 22, 2009 7:23 PM +0200 Luca Scamoni luca.scamoni@sys-net.it wrote:
Quanah Gibson-Mount ha scritto:
--On Wednesday, April 22, 2009 10:52 AM +0200 "SAGNIMORTE Thomas
I set entry cache to 100000, idlcache to 10000 and dncache to 10000.
Seems reasonable.
Since cachesize is 100K entries shouldn't idlcachesize be 300K ? (he's
using hdb backend)
Hm, I read that all as 10k. I'm guessing that a 100k cachesize and a 10k idlcachesize wouldn't be greatly productive, but I've often run my HDB backends with the same cachesize/idlcachesize without ill effect.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Monday, April 27, 2009 5:53 PM +0200 "SAGNIMORTE Thomas (CAMPUS)" thomas.sagnimorte@oxylane-group.com wrote:
Hi,
Thanks for this information.
I look on backtrace with gdb and I have got this one. I hope this is what your except.
I join more detail, could you read it?
Thanks,
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1132489024 (LWP 11645)] 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 (gdb) backtrace full # 0 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 No symbol table info available. # 1 0x00000000004c7ea1 in hdb_cache_delete_cleanup () No symbol table info available.
Well, it looks like you built OpenLDAP without debugging symbols (The "-g" CFLAGS option), so no useful data can be obtained from this backtrace, other than the problem occurred in hdb_cache_delete_cleanup, which is something anyhow.
Please rebuild your OpenLDAP with:
CFLAGS="-g -O0"
set.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
All right. I we do this and send you the good gdb file.
Regards,
Thomas
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Monday, April 27, 2009 5:58 PM To: SAGNIMORTE Thomas (CAMPUS); Luca Scamoni Cc: openldap-technical@openldap.org Subject: RE: Segfault during Auth Benchmark request
--On Monday, April 27, 2009 5:53 PM +0200 "SAGNIMORTE Thomas (CAMPUS)" thomas.sagnimorte@oxylane-group.com wrote:
Hi,
Thanks for this information.
I look on backtrace with gdb and I have got this one. I hope this is what your except.
I join more detail, could you read it?
Thanks,
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1132489024 (LWP 11645)] 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 (gdb) backtrace full # 0 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 No symbol table info available. # 1 0x00000000004c7ea1 in hdb_cache_delete_cleanup () No symbol table
info available.
Well, it looks like you built OpenLDAP without debugging symbols (The "-g" CFLAGS option), so no useful data can be obtained from this backtrace, other than the problem occurred in hdb_cache_delete_cleanup, which is something anyhow.
Please rebuild your OpenLDAP with:
CFLAGS="-g -O0"
set.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi,
Please find attach the new version of gdb.
I am not sure that it change a lot.
Regards,
Thomas
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Monday, April 27, 2009 5:58 PM To: SAGNIMORTE Thomas (CAMPUS); Luca Scamoni Cc: openldap-technical@openldap.org Subject: RE: Segfault during Auth Benchmark request
--On Monday, April 27, 2009 5:53 PM +0200 "SAGNIMORTE Thomas (CAMPUS)" thomas.sagnimorte@oxylane-group.com wrote:
Hi,
Thanks for this information.
I look on backtrace with gdb and I have got this one. I hope this is what your except.
I join more detail, could you read it?
Thanks,
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1132489024 (LWP 11645)] 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 (gdb) backtrace full # 0 0x0000003c024082e9 in pthread_mutex_lock () from /lib64/libpthread.so.0 No symbol table info available. # 1 0x00000000004c7ea1 in hdb_cache_delete_cleanup () No symbol table
info available.
Well, it looks like you built OpenLDAP without debugging symbols (The "-g" CFLAGS option), so no useful data can be obtained from this backtrace, other than the problem occurred in hdb_cache_delete_cleanup, which is something anyhow.
Please rebuild your OpenLDAP with:
CFLAGS="-g -O0"
set.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Monday, April 27, 2009 7:27 PM +0200 "SAGNIMORTE Thomas (CAMPUS)" thomas.sagnimorte@oxylane-group.com wrote:
Hi,
Please find attach the new version of gdb.
I am not sure that it change a lot.
Your binary has been stripped after building, see how it says "no debugging symbols found".
When you run "make install" you likely need to specify STRIP=""
I.e.:
make install STRIP=""
so that it will not strip out the debugging symbols when it installs the new build.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Ok, I have reinstall openldap with the symbol. I think it is ok now.
Regards,
Thomas
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Monday, April 27, 2009 7:41 PM To: SAGNIMORTE Thomas (CAMPUS); Luca Scamoni Cc: openldap-technical@openldap.org Subject: RE: Segfault during Auth Benchmark request
--On Monday, April 27, 2009 7:27 PM +0200 "SAGNIMORTE Thomas (CAMPUS)" thomas.sagnimorte@oxylane-group.com wrote:
Hi,
Please find attach the new version of gdb.
I am not sure that it change a lot.
Your binary has been stripped after building, see how it says "no debugging symbols found".
When you run "make install" you likely need to specify STRIP=""
I.e.:
make install STRIP=""
so that it will not strip out the debugging symbols when it installs the new build.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org