--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

--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

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

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