openldap-devel

openldap-devel@openldap.org

1418 discussions

Please test RE24
by Howard Chu 23 Oct '07

23 Oct '07

I don't remember if we posted this already or not. We're prepping 2.4.6 for release; please test RE24 and submit any problems you encounter to the ITS. Likewise, RE23 looks about ready. If you're interested in 2.3.39 please test and report results for RE23 as well. Currently all tests in RE24 pass for me on OpenSUSE 10.2 x86_64 and FedoraCore6 x86_64. -- -- 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/

4 6

ITS#4943 tpool.c, thread pools
by Howard Chu 20 Oct '07

20 Oct '07

I presume we can close this ITS now. I've been running some tests on a quad-processor AMD system, and seeing a lot of mutex contention in the frontend. It looks like the current threadpool and connection manager architecture are a bad fit for a NUMA system like this. I'm planning to add support for multiple thread pools (one per CPU would be the idea) and multiple listener threads to slapd. As a first step, after 2.4.6 is released, I'm going to unifdef the SLAPD_LIGHTWEIGHT_DISPATCHER symbol and delete the old dispatcher code. Based on some experimental changes I've already made, I see a difference between 25K auths/sec with the current code, vs 39K auths/sec using separate thread pools. -- -- 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/

2 3

Re: commit: ldap/doc/man/man8 slapadd.8
by Howard Chu 17 Oct '07

17 Oct '07

quanah(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/doc/man/man8 > > Modified Files: > slapadd.8 1.46 -> 1.47 > > Log Message: > ITS#5189 add note about db_stat and slapd needing to be run when using quick mode. This note is incorrect and inappropriate. It is inappropriate because db_stat is a BerkeleyDB specific command, it has no relevance to the generic features of slapadd. It is incorrect because most other db_stat options still work. db_stat -c is not "broken" here either; db_stat -c attempts to return lock status information and it correctly tells you that there is no lock information to return. That is not an error, nor does it need fixing. -- -- 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/

2 1

Setting up slapo-pcache with back-config
by Ralf Haferkamp 16 Oct '07

16 Oct '07

Hello, is slapo-pcache supposed to work with back-config with current HEAD? I was not able to create a working configuration, yet. As soon as the olcPcacheConfig Entry is added as a child below a back-ldap Database Entry, slapd tries to open the corresponding bdb/hdb Database for the pcache overlay, which of course does not yet exist as it has to be a child object of the olcPcacheConfig Entry. Any suggestions how this could be fixed? -- Ralf

2 4

Handling bad cn=config updates
by Hallvard B Furuseth 16 Oct '07

16 Oct '07

If I modify olcDbDirectory of a BDB database to a broken directory, the Modify returns success but BDB says "failed to reopen database" and slapd shuts down. Maybe other modifications can shut down slapd too, I don't know. It would be nice if slapd tried to restore the old config value, reopen the old directory, and return unwillingToPerform or something to the Modify. However I don't know how hard that would be, or how obscure a case it is. For that matter, maybe if the Modify broke something it could return some diagnosticMessage. Not sure if it should return non-success since that supposedly means the modify did not happen. Though clients may not display the diagnosticMessage if it comes with 'success'. -- Hallvard

3 8

Re: commit: ldap/servers/slapd/back-bdb config.c
by Pierangelo Masarati 15 Oct '07

15 Oct '07

> Check DB directory validity at config time Of course, there's no guarantee the directory will exist and be writable when really needed ;) Just wanted to note it, I understand it should be considered as likely as someone running rm -rf on the database directory while slapd is running... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

2 1

Move LDAP_DEVEL features into 2.4?
by Pierangelo Masarati 14 Oct '07

14 Oct '07

I have few enhancements that could go into 2.4 based on consensus. - BDB_MONITOR_IDX: monitor missing indices in searches. Let me remember that this feature allows to monitor (thru cn=Monitor) how many search candidate selections missed an index, and what index type. It costs a mutex lock/unlock for each call to bdb_index_param(). - pcache private database access: add a control and an exop that allow access to the private database for administrative/monitoring purposes, and consistent cached query removal (namely: removal of a specific query and related queryID from participating entries; removal of an entry and invalidation of all related queries, ...) Please comment. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

2 3

Monitoring slapd entities...
by Pierangelo Masarati 14 Oct '07

14 Oct '07

What back-monitor does in many cases is monitoring entities living inside slapd. In those cases, the living entity and back-monitor's entry should be in touch with each other to account for reciprocal updating. The flow of information, so far, has been handled in one direction by providing a neutral interface (actually, two): - the per-subsystem hooks - the callbacks Callbacks are much more general than per-subsystem hooks. I think per-subsystem stuff should be eliminated, as they basically duplicate callbacks with less flexibility. However, I believe bi-directional communication could make many things much easier. Let's think what operations may require either direction: back-monitor needs to be able to ask living entries information when it is asked to present entries (e.g. in response to a search). For this purpose, the current callback mechanism should be sufficient. However, living entities may need to contact back-monitor for many purposes: to register new callbacks, to add/remove themselves to/from back-monitor. For this latter purpose, a solution could be to augment all living entities with a pointer to their entry in back-monitor. This pointer should be set by back-monitor as soon as that entry is created. This would ease feature registration by acting as a key (the caller would finally know the real DN of its entry), rather than figuring out a mechanism to locate it as it is currently done by the monitor_back_register_* calls. Basically, BackendInfo, BackendDB, overlay_info and overlay_inst would need an (Entry * (*)_monitor) to their entry in back-monitor, to be mostly used as a key when calling monitor-related functions. Other structures in the future may need it, but the interface would be general enough to allow extensions. Comments? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

2 1

ITS#4787: Download links with version vs. date
by Michael Ströder 11 Oct '07

11 Oct '07

Hope it's ok to take this to openldap-devel. Kurt Zeilenga wrote: > ITS#4787: requests change in "stable" release naming. More discussion > needed. (I oppose making this change for various reasons). What are these "various reasons"? Ciao, Michael.

2 1

New performance numbers
by Howard Chu 11 Oct '07

11 Oct '07

Back in May 2006 we posted some authentication rate numbers for Symas CDS 3.3.2 (based on OpenLDAP 2.3.21.) http://connexitor.com/blog/pivot/entry.php?id=49 On a 1 million entry database, we saw about 13K auths/second on a dual processor 2.8GHz Opteron system. We've recently re-run the tests using OpenLDAP 2.4.5 on a dual processor 2.8GHz dual-core Opteron system (so, 4 cores now instead of just 2) and gotten 38K auths/second. One interesting thing to note is that we reached this same rate on back-bdb, with the slapd server at 100% CPU utilization, as well as with back-null, where slapd was only at 70% CPU. (This implies to me that there may have been a network bottleneck here, because we ought to have been able to drive slapd into 100% CPU usage even with back-null. Even gigabit ethernet has its limits...) But the other nice point about this result is that while the number of CPU cores was increased by a factor of 2, the overall auth rates increased by a factor of 2.7. So we can see that OpenLDAP 2.4 is at least 35% faster than OpenLDAP 2.3. It also shows that the lightweight dispatcher is still scaling well with available CPU power. Another point is the same thing I've harped on before - SLAMD is too inefficient on clients. We measured the 38K/sec rate using the slapd-auth C client that I just added to CVS HEAD. Using the SLAMD java client we could only reach 29K/sec, even with 12 client machines and 10 threads per client. Someone's going to have to sit down and write a C client that speaks the SLAMD server protocol and just fires off compiled C clients... -- -- 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 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel