Re: Need help to tune 389 DS

[wodel youchi <wodel.youchi@xxxxxxxxx>]

Hi,

And thanks for your replies.

We 're using cn=Directory Manager, for now, because we have a problem with the password module of the horde groupware, we tried to use the self change password, but it didn't work we got this error "constraint violation".

Concerning the filter 'objectClass=*', it's not used on the mail server, I will investigate this with the webmaster to see which filters used, and try to correct them.

Another question, is it wise to refuse unindexed searches, and switch 'nsslapd-require-index' to 'on' as suggested by the logconv script ?

Regards.

2017-02-23 18:08 GMT+01:00 Mark Reynolds <mareynol@xxxxxxxxxx>:

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@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org

_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx