[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldap query performance issue

Meike Stone wrote:

Hello,

had the same problem years ago and the patch worked for me. As I
understood, this special problem exist in mdb too
(http://www.openldap.org/lists/openldap-technical/201301/msg00185.html)
Thats one reason, because I did not switch till now.
Yes, back-mdb uses the same index design, but it is still inherently faster than BDB backends. 

Thanks Meike

2013/5/24 Howard Chu <hyc@symas.com>:

Chris Card wrote:


Any ideas?



Increase the IDL range. This is how I do it:

--- openldap-2.4.35/servers/slapd/back-bdb/idl.h.orig 2011-02-17
16:32:02.598593211 -0800
+++ openldap-2.4.35/servers/slapd/back-bdb/idl.h 2011-02-17
16:32:08.937757993 -0800
@@ -20,7 +20,7 @@
/* IDL sizes - likely should be even bigger
* limiting factors: sizeof(ID), thread stack size
*/
-#define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17
*/
+#define BDB_IDL_LOGN 17 /* DB_SIZE is 2^16, UM_SIZE is 2^17
*/
#define BDB_IDL_DB_SIZE (1<<BDB_IDL_LOGN)
#define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+1))
#define BDB_IDL_UM_SIZEOF (BDB_IDL_UM_SIZE * sizeof(ID))


Thanks, that looks like it might be the issue. Unfortunately I only see
the issue in production, so patching it might be a pain.


I've tried this change, but it made no difference to the performance of
the query.



You have to re-create all of the relevant indices as well. Also, it's always
possible that some slots in your index are still too big, even for this
increased size.

You should also test this query with your data loaded into back-mdb.
--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/






--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/