On 02/23/2017 11:53 AM, Steve Holden wrote:
> -----Original Message-----
> From: Mark Reynolds [mailto:email@example.com]
> Sent: 23 February 2017 16:00
> To: General discussion list for the 389 Directory server project. <389-
> Subject: [389-users] Re: Need help to tune 389 DS
> On 02/23/2017 10:48 AM, Gordon Messmer wrote:
>> On 02/23/2017 12:11 AM, William Brown wrote:
>>> As Noriko pointed you, you are missing nsIndexType: pres on this
>> I hate to repeat myself, but is that a thing that changed *recently*?
> No, it has always only been indexed for "eq".
> As Rich said, having a "pres" index on objectclass is redundant(and
> wasteful). Every entry has objectclass - so if this was indexed for
> "presence" it could actually create overhead. It's faster to read
> directly from the DB, or candidate list, than trying to use an index
> that contains every entry anyway.
We've seen similar problems (and weren't sure whether the objectClass
issues were part of broader indexing issues - more on that separately).
We discourage the use of '(objectClass=*)' as a (partial) filter for precisely
the reason Mark mentions - but one of our applications is hard-coded to
use it, and our monitoring tools are highlighting that searches which contain
that *partial* filter are being logged as partially unindexed:
conn=3921153 op=1 SRCH base="ou=people,dc=brighton,dc=ac,dc=uk"
scope=2 filter="(&(objectClass=*)(uid=USERNAME))" attrs=ALL
conn=3921153 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=U
Would you recommend we just ignore these warnings?
Yes it can be ignored since the
etime is 0. It's always about the etimes :)
And am I right in assuming you wouldn't recommend adding 'nsIndexType: pres'
to 'cn=objectclass,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
as it wouldn't actually improve performance? (and would just generate a 1:1 map of
Right, do not use "pres" for objectclass
Out of interest, is there a reason why a filter which *only* includes
doesn't do that...?
conn=3914283 op=1 SRCH base="uid=USERNAME,ou=People,dc=brighton,dc=ac,dc=uk"
scope=0 filter="(objectClass=*)" attrs=ALL
conn=3914283 op=1 RESULT err=0 tag=101 nentries=1 etime=0
Or is that just because in this case the base is the uid (not the branch above it)?
Correct, because it's a base search (scope=0) the filter does not need
to scan the database - only the target/base entry is checked.
This email has been scanned by MessageLabs' Email Security System
on behalf of the University of Brighton. For more information see:
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org