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.

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*