On 02/23/2017 11:53 AM, Steve Holden wrote: >> -----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? 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 every entry!) Right, do not use "pres" for objectclass > > > 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)? 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. Regards, Mark > > 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 _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
