> -----Original Message----- > From: Mark Reynolds [mailto:mareynol@xxxxxxxxxx] > Sent: 23 February 2017 16:00 > To: General discussion list for the 389 Directory server project. <389- > users@xxxxxxxxxxxxxxxxxxxxxxx> > 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. Hi, folks 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? 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 every entry!) Out of interest, is there a reason why a filter which *only* includes 'objectClass=*' 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)? Best wishes, Steve ___________________________________________________________ This email has been scanned by MessageLabs' Email Security System on behalf of the University of Brighton. For more information see: https://staff.brighton.ac.uk/is/computing/Pages/Email/spam.aspx _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
