On 11/5/19, 14:29, "William Brown" <wbrown(a)suse.de> wrote:
On 6 Nov 2019, at 07:22, Iain Morgan <Iain.Morgan(a)nasa.gov>
wrote:
Hello,
The list server seems to have delayed the original message for
moderation, so I'mtrying again with a different subject.
I should note that the issue below may not be new: Even with our
previous generation of LDAP servers, our regression tests were only ever
run againsta single, non-replicated server.
--
Iain Morgan
---- Forwarded message from Iain Morgan <Iain.Morgan(a)nasa.gov> -----
Date: Mon, 4 Nov 2019 17:11:52 -0800
From: Iain Morgan <Iain.Morgan(a)nasa.gov>
To: 389-users(a)lists.fedoraproject.org
Subject: Unexpected 'admin limit exceeded' error
Hello,
I have a set of tests that are run against 389s a large number of times
as part of our regular testing. The tests primarily simulate account and
group
group management operations although there is also some testing of the
password policy enforcement.
These tests were running fine against a single server configured without
replication. However, I recently started running these tests against a
server that is configured for multi-master replication with another host
running the same version of 389-ds.
After successfully completing more than 700 iterations of the test suite, the tests
unexpectedly failed
with err=11 while doing a a search. The curious thing is that the log
message reports nentries=1.
[04/Nov/2019:15:23:50.792301129 -0800] conn=479376 op=2 SRCH
base="ou=People,dc=nas,dc=nasa,dc=gov" scope=2
filter="(|(uid=testacct)(uid=aftertest))" attrs="1.1"
[04/Nov/2019:15:23:50.804542570 -0800] conn=479376 op=2 RESULT err=11 tag=101 nentries=1
etime=0.0012354224
Looking this up, it looks like err=11 is an administrative limit error, so it's
likely that the partial-candidate set during index searching was larger than your limits
allows.
This could be due to the following settings:
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_do...
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_do...
If my memory is correct, lookthroughlimit is how many entries we will filter-test in a
candidate set (such as a full table scan scenario, or a really large query that is not
fully indexed), and idlistscanlimit is a limit on how large an index list can be (in an
attempt to discard large indexes hoping a smaller candidate index appears later in the
query, essentially a naive form of query optimisation). As a result this makes me consider
perhaps it's an indexing related problem?
It may also be worth checking you have correct indexes for uid= under:
dn: cn=uid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
(Ignore dn: cn=uid,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config
as this is a template index definition, and does not affect your actual indexing
procedures.)
Followed by potentially re-indexing your DB.
You can always check your indexes are in good states with:
cd /var/lib/dirsrv/slapd-instance/db/<backend name>/
dbscan -f uid.db4 -n -k "=testacct"
dbscan -f uid.db4 -n -k "=aftertest"
Both should have output like:
=testacct <some integer greater than 0>
Does that help?
Thanks, that input was definitely helpful.
The dbscan output appears to confirm that it is an indexing issue. Combining the results
from dbscan for the two uid's shows that it was indeed hitting the
nsslapd-lookthroughlimit setting.
I'm not sure why it was not encountering this issue prior to setting up replication.
I've previously run several thousand iterations of these tests without hitting this
problem. Running db2index.pl has cleaned things up, so I suppose a workaround would be to
have the test suite run db2index.pl after some number of iterations.
--
Iain Morgan