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 <gera...@gmail.com >> <mailto:gera...@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* >
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
