Hello,
because of this, does it make sense in a directory with > 1,000,000
people to index the sex?
thanks Meike
2013/5/23 Quanah Gibson-Mount <quanah(a)zimbra.com>:
--On Thursday, May 23, 2013 4:40 PM +0000 Chris Card
<ctcard(a)hotmail.com>
wrote:
> Hi all,
>
> I have an openldap directory with about 7 million DNs, running openldap
> 2.4.31 with a BDB backend (4.6.21), running on CentOS 6.3.
>
> The structure of the directory is like this, with suffix dc=x,dc=y
>
> dc=x,dc=y
> account=a,dc=x,dc=y
> mail=m,account=a,dc=x,dc=y // Users
> ....
> licenceId=l,account=a,dc=x,dc=y // Licences,
> objectclass=licence ....
> group=g,account=a,dc=x,dc=y // Groups
> ....
> // etc.
>
> account=b,dc=x,dc=y
> ....
>
> Most of the DNs in the directory are users or groups, and the number of
> licences is small (<10) for each account.
>
> If I do a query with basedn account=a,dc=x,dc=y and filter
> (objectclass=licence) I see wildly different performance, depending on
> how many users are under account a. For an account with ~30000 users the
> query takes 2 seconds at most, but for an account with ~60000 users the
> query takes 1 minute.
>
> It only appears to be when I filter on objectclass=licence that I see
> that behaviour. If I filter on a different objectclass which matches a
> similar number of objects to the objectclass=licence filter, the
> performance doesn't seem to depend on the number of users.
>
> There is an index on objectclass (of course), but the behaviour I'm
> seeing seems to indicate that for this query, at some point slapd stops
> using the index and just scans all the objects under the account.
>
> 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))
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration