On 01/03/2018 01:03 PM, Sergei Gerasenko wrote:
For #1, I see the -u option, which does give me the name of the unindexed entries. So, I think I can figure this one out from here.

On Jan 3, 2018, at 11:58 AM, Sergei Gerasenko <gerases@gmail.com> wrote:

Ok, thank you. I think the exact description of that counter is (from 389-ds-base-1.3.5.10/ldap/servers/snmp/redhat-directory.mib):

    dsErrors  OBJECT-TYPE
        SYNTAX Counter64
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
          " Number of operations that could not be serviced
            due to errors other than security errors, and
            referrals.
            A partially serviced operation will not be counted
            as an error.
            The errors include NameErrors, UpdateErrors, Attribute
            errors and ServiceErrors."
        REFERENCE
          " CCITT Blue Book Fascicle VIII.8 - Rec. X.511, 1988:
            Sections 12.4, 12.5, 12.8 & 12.9. and, RFC1777 Section 4."
        ::= {dsOpsEntry 20}

Didn’t know about logconv.pl. Nice tip. Running it with -ej produced:

----- Errors -----

err=0                  9560    Successful Operations
err=14                  330    SASL Bind in Progress
err=32                  161    No Such Object

----- Recommendations -----

 1.  You have unindexed components, this can be caused from a search on an unindexed attribute, or your returned results exceeded the allidsthreshold.  Unindexed components are not recommended. To refuse unindexed searches, switch 'nsslapd-require-index' to 'on' under your database entry (e.g. cn=UserRoot,cn=ldbm database,cn=plugins,cn=config).

 2.  You have a significant difference between binds and unbinds.  You may want to investigate this difference.
To be honest these "recommendations" aren't very accurate.  If you look at the unindexed searches reported by logconv.pl you should only be concerned about ones that have an etime greater than zero.  Some "unindexed searches" are not bad, only the ones with high etimes.

For #1, can I identify the unindexed attributes and create the indeces? For #2, does it mean that some binds hang around without being closed? What’s the best way to investigate #2 further?

Thanks, Mark.



Any time an error occurs on a search or write operation this counter is incremented.  Look in the DS access logs for anything that is not "err=0" to see what the exact errors are.  I suggest running logconv.pl to make this easier:

# logconv.pl -e /var/log/dirsrv/slapd-YOUR_INSTANCE/access*