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

Re: (ITS#7567) Alias dereferencing slowness



luca.scamoni@gruppopa.it wrote:
> Full_Name: Luca Scamoni
> Version: 2.4.35
> OS: Linux
> URL: ftp://www.sys-net.it/alias-deref-ITS2.tar.gz
> Submission from: (NULL) (78.134.117.13)
>
>
> Investigating alias dereferencing slowness on a customer production system I
> came upon a suspect behaviour with back-hdb/bdb.
> It seems that slapd, when dereferencing, instead of looking for the exact
> aliased DN, starts scanning more entries than needed (at least this is what I
> can tell looking to the logs set to log anything)
> On the customer system, with over 700,000 entries, the time taken to perform a
> simple search with alias dereferencing for a single entry, takes as much as
> performing a full ldapsearch of the entire ldap tree.
> To reproduce I created a small testcase (that I can't upload because there's no
> space left on ftp.openldap.org/incoming). The test case contains also the log
> and the operations performed on test data to show the issue.
> I tested with openldap 2.4.23, 2.4.31 and 2.4.35. The issue is present in all
> versions but seems to manifest itself only with back-bdb/hdb. Back-mdb seems not
> to show the issue (even looking at the logs) but right now, moving to back-mdb
> is not something the customer is ready to take.

I would not recommend switching to back-mdb at this time, see ITS#7577. Alias 
dereferencing is broken in a few cases in back-mdb.

Meanwhile, in back-bdb/hdb, it also depends on whether you're searching with 
Deref set to Finding, Searching or Always. Deref/Finding works in all 3 
backends (bdb/hdb/mdb). (Deref/Searching in back-mdb was mainly broken by the 
patches in ITS#7473.)

When Deref is set to Searching/Always, the backend must find every alias 
within the target search scope and dereference them. This deref can 
potentially expand the scope of the search, e.g. if the alias points to a 
completely different subtree. If you have a lot of aliases in the tree, this 
is likely going to be very slow.

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