On 11/5/19, 14:29, "William Brown" <wbrown@xxxxxxx> wrote:
> On 6 Nov 2019, at 07:22, Iain Morgan <Iain.Morgan@xxxxxxxx> 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@xxxxxxxx> -----
>
> Date: Mon, 4 Nov 2019 17:11:52 -0800
> From: Iain Morgan <Iain.Morgan@xxxxxxxx>
> To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> 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_documentation_en-2Dus_red-5Fhat-5Fdirectory-5Fserver_10_html_configuration-5Fcommand-5Fand-5Ffile-5Freference_database-5Fplug-5Fin-5Fattributes-23nsslapd-2Dlookthroughlimit&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=SxxzZkP0cGnBH8cCF9mvxKQPsiiT3FXk9Hep02qrOfw&m=Rc__45h_pVBKYz8gdbtA2EmnhTRLdcqnIf7PItwTqH8&s=NiKMto2vdIN8wvDM9FquM2goaXNmcarUdTSo4w_oj90&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2Dus_red-5Fhat-5Fdirectory-5Fserver_10_html_configuration-5Fcommand-5Fand-5Ffile-5Freference_database-5Fplug-5Fin-5Fattributes-23nsslapd-5Fidlistscanlimit&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=SxxzZkP0cGnBH8cCF9mvxKQPsiiT3FXk9Hep02qrOfw&m=Rc__45h_pVBKYz8gdbtA2EmnhTRLdcqnIf7PItwTqH8&s=LS5bTaI07IaTqZ26b9PpWkxveGIyPpY1vrVt35A2keM&e=
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
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
