Re: Need help to tune 389 DS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----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




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux