Re: monitoring

[Mark Reynolds <mreynolds@xxxxxxxxxx>]

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@xxxxxxxxx> 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*

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