> 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://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/database_plug_in_attributes#nsslapd-lookthroughlimit https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/database_plug_in_attributes#nsslapd_idlistscanlimit 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? > > > No error is logged in the error log. This is on RHEL 7.7 with the > 1.3.9.1-10 RPMs provided by Red Hat. > > > -- > Iain Morgan > > ----- End forwarded message ----- > > -- > 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 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 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
