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(a)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.
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*