It was set to the default (4000). I set it to 700000, and now both searches are fast (initial run time 3 seconds, then instant). And the server logs don't show any 'notes=?' for either search.

 

But… that's not what the docs say to do?

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/improving-search-performance.html#setting-scan-limits

 

So basically, setting nsslapd-idlistscanlimit big tells the server to NOT revert to unindexed search, and indexed search makes me happy in this case.

But why is unindexed search on ou=PEOPLE so much faster than on ou=STUDENTS,ou=RECORDS?

Or should I not care what the answer to that question is and just set nsslapd-idlistscanlimit to a million and be happy?

 

Thanks for your help,

Anthony

 

From: Noriko Hosoi [mailto:nhosoi@redhat.com]
Sent: Thursday, February 16, 2017 5:16 PM
To: 389-users@lists.fedoraproject.org
Subject: [389-users] Re: elapsed time gremlin

 

Hello,

What is the value set to nsslapd-idlistscanlimit?

$ ldapsearch -x -LLL -H ldaps://ldap.example.com:636 -b  'cn=config,cn=ldbm database,cn=plugins,cn=config' -D cn=Directory\ Manager -w password -s base nsslapd-idlistscanlimit

If it is less than 6000, could you increase it to some large number, e.g., 700000, and retry the searches?

Thanks,
--noriko

On 02/16/2017 04:54 PM, Winstanley, Anthony wrote:

Hi,

I'm hoping somebody can tell me where I might look to find why this is happening…

We're running 389-Directory/1.2.11.15 B2014.300.2010

 

I have two ldapsearch queries that only vary in searchbase, one which is taking too long. (Times don't vary much with consecutive executions.)

ou=PEOPLE has just under 700,000 entries. Search takes 0-3 seconds.

ou=STUDENTS,ou=RECORDS has just under 6000 entries. Search takes 123-126 seconds.

There are no attributes used in ou=STUDENTS,ou=RECORDS that aren't also used in ou=PEOPLE.

 

Two sample executions and log output:

 

[user@workstation ~]$ ldapsearch -x -LLL -H ldaps://ldap.example.com:636 -b ou=STUDENTS,ou=RECORDS,dc=example,dc=com -D cn=Directory\ Manager -w password -s one -z 5 'cn=*' dn

… 5 entries returned …

[user@workstation ~]$

[root@server slapd-ldap1]# grep conn=33505 access

[16/Feb/2017:16:31:37] conn=33505 fd=96 slot=96 SSL connection from IP1 to IP2

[16/Feb/2017:16:31:37] conn=33505 SSL 256-bit AES

[16/Feb/2017:16:31:37] conn=33505 op=0 BIND dn="cn=Directory Manager" method=128 version=3

[16/Feb/2017:16:31:37] conn=33505 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"

[16/Feb/2017:16:31:37] conn=33505 op=1 SRCH base="ou=STUDENTS,ou=RECORDS,dc=example,dc=com" scope=1 filter="(cn=*)" attrs="distinguishedName"

[16/Feb/2017:16:33:40] conn=33505 op=1 RESULT err=4 tag=101 nentries=5 etime=123 notes=A

[16/Feb/2017:16:33:40] conn=33505 op=2 UNBIND

[16/Feb/2017:16:33:40] conn=33505 op=2 fd=96 closed - U1

[root@server slapd-ldap1]#

 

 

[user@workstation ~]$ ldapsearch -x -LLL -H ldaps://ldap.example.ca:636 -b ou=PEOPLE,dc=example,dc=com -D cn=Directory\ Manager -w password -s one -z 5 'cn=*' dn

… 5 entries returned …

[user@workstation ~]$

[root@server slapd-ldap1]# grep conn=33578 access

[16/Feb/2017:16:38:43] conn=33578 fd=96 slot=96 SSL connection from 142.103.30.27 to 10.7.128.16

[16/Feb/2017:16:38:44] conn=33578 SSL 256-bit AES

[16/Feb/2017:16:38:44] conn=33578 op=0 BIND dn="cn=Directory Manager" method=128 version=3

[16/Feb/2017:16:38:44] conn=33578 op=0 RESULT err=0 tag=97 nentries=0 etime=1 dn="cn=directory manager"

[16/Feb/2017:16:38:44] conn=33578 op=1 SRCH base="ou=PEOPLE,dc=example,dc=com" scope=1 filter="(cn=*)" attrs="distinguishedName"

[16/Feb/2017:16:38:44] conn=33578 op=1 RESULT err=4 tag=101 nentries=5 etime=0 notes=A

[16/Feb/2017:16:38:44] conn=33578 op=2 UNBIND

[16/Feb/2017:16:38:44] conn=33578 op=2 fd=96 closed - U1

[root@server slapd-ldap1]#

 

 

Help? This is driving me nuts… Where can I look to find out why this might be happening?

 

Thanks,

Anthony




_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org