openldap-devel February 2008

openldap-devel@openldap.org

25 participants
20 discussions

icu -- is it the "recommended" OpenLDAP unicode implementation?
by Xin LI 18 Feb '08

18 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'd like to get an inquiry about the state of OpenLDAP's unicode implementation. Recently there is some reports that the FreeBSD port of OpenLDAP 2.4.x will pick up icu automatically if it is installed, according to the configure script, it seems that there is no way to disable this behavior (i.e. by --disable-icu or something similar), so it seems that a patch will be necessary if the user does not want to use icu. So my question is that, is it recommended to use icu? I am thinking about making icu an mandatory dependency of the port, but I guess it would be good to ask the developers before making such changes :) Cheers, - -- Xin LI <delphij(a)delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHuP63i+vbBBjt66ARAiqcAKCuxW9xJW3qVataZpBeKVjBhbXHcQCffYy/ JhU4ZOghLdrGzYHTzQt7Ey8= =xTGY -----END PGP SIGNATURE-----

2 2

Anyone use ccache?
by Gavin Henry 18 Feb '08

18 Feb '08

Just curious, does anyone use ccache when compile/developing etc.? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

2 1

RE23 testing
by Quanah Gibson-Mount 17 Feb '08

17 Feb '08

Please test RE23 in preparation for OpenLDAP 2.3.41. Thanks, Quanah+ -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

12 25

Thread pool efficiency
by Howard Chu 16 Feb '08

16 Feb '08

Testing on an 8-socket AMD server with Opteron 885 dual-core processors (16 cores total) and a Sun T5120 (T2 Niagara 8 cores, 64 hardware threads) has shown that our current frontend code is performing very poorly with more than 16 server threads. E.g. on the AMD system with 16 cores allocated, performance was still slower than on the 4-socket AMD server with Opteron 875 dual-core processors (despite 2x the cores and a significant clock-speed advantage). Testing also showed that in this configuration, at least one of the 16 cores was always 100% idle. Basically, the frontend cannot hand out work fast enough to the worker threads. Rather than using a single mutex to control all accesses into the thread pool, I think we need to have separate queues per worker thread. The frontend can operate in single-producer mode where only the single listener thread is allowed to submit jobs into the pool. The workers can just access their own individual work queues, thus significantly reducing mutex contention. Ideally we would arrange things such that any data structure is only ever written by a single thread, and all other threads only perform reads against it. (And in the best case, only one other thread needs to perform that read.) By eliminating memory ownership changes and unnecessary cache line sharing, we can dramatically reduce the cache coherency traffic. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 14

RE23 final call for testing
by Quanah Gibson-Mount 15 Feb '08

15 Feb '08

A few issues were identified in the last round of testing. If people could test again with current RE23 CVS that would be much appreciated. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

8 12

RE24 final call for testing
by Quanah Gibson-Mount 14 Feb '08

14 Feb '08

A few issues were identified in the last round of testing. If people could test again with current RE24 CVS that would be much appreciated. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

6 5

Re: thread pools, performance
by Howard Chu 14 Feb '08

14 Feb '08

Rick Jones wrote: > There are definitely interrupt coalescing settings available with tg3-driven > cards, as well as bnx2 driven ones: > > ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt Yep, that helped. Raising rx-usecs from default 20 to 1000, and rx-frames from default 5 to 100, I'm getting 43k auths/sec with back-null (in 4 separate thread pools) and the core fielding the interrupts is only about 80% busy now instead of 100%. I'm afraid my load generators may be maxed out now, because I can't seem to drive up the load on the server any higher even though there's more idle CPU. The current code in HEAD (with only 1 thread pool) is reaching 36k auths/sec with back-null, so it's actually not far off from my experimental peak rate. Considering that HEAD was at 25k/sec last week (and now in 2.4.6) that's pretty decent. With back-bdb and 1 million users I'm getting 26.1k/sec with plaintext passwords (up from 19.3k/sec last week). With {SSHA} passwords that drops to 25.7k/sec (~1.5% difference). I have to put this tinkering on hold for a bit, to run some authrate tests against ActiveDirectory on this machine (using W2K3sp2 X64). Later on we'll do a W2K3 OpenLDAP build for comparison as well. Should be entertaining... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

7 22

Re: RE24 testing
by Luca Scamoni 13 Feb '08

13 Feb '08

Passes on CentOS 4.6 and CentoOS 5.1 (i686 and virtual machines) I had only one run in which test050 seemed to have been gone in a sort of loop on a CentOS 4 VM, but I've not been able to reproduce it in more than 20 runs of the test. 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) Mobile: +39 347 1014425 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

RE24 testing
by Quanah Gibson-Mount 12 Feb '08

12 Feb '08

Please test RE24 in preparation for 2.4.8. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

5 8

Re: commit: ldap/libraries/libldap_r tpool.c
by Hallvard B Furuseth 04 Feb '08

04 Feb '08

Howard, do you remeber if this was a bug fix or an optimization? If the former it was merely triggering some other bug which can presumably still happen due to spurious wakeups. Or if the problem is that the cond can be destroyed at this point if the pool is tearing down, so can the mutex - even though it is locked here. At Thu, 18 Oct 2007, hyc wrote: > tpool.c 1.80 -> 1.81 > > In pool_resume don't touch the condvar if the pool is tearing down. It's this patch to ldap_pvt_thread_pool_resume(), aka "pool_resume fix from HEAD" in the CVS comment for import to RE24: @@ -704,3 +704,4 @@ pool->ltp_pause = 0; - ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); + if (pool->ltp_state == LDAP_INT_THREAD_POOL_RUNNING) + ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); ldap_pvt_thread_mutex_unlock(&pool->ltp_mutex); -- Hallvard

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel February 2008