If the answers given below are not satisfactory, please file tickets for all of these issues at https://fedorahosted.org/389/newticket.  Also, since you appear to be a Red Hat DS customer, please open cases with RH support.

On 01/21/2014 12:19 PM, Colin Tulloch wrote:

Hi All –

 

I’ve got another one today.

 

We have 1 attribute in our infrastructure that’s extremely large – it’s a PKI CRL that’s around 15MB.  It sits in an entry that has about 6300 sub entries.


That shouldn't necessarily be a problem.  We have customers with 100MB CRL entries.

 

We had some previously mentioned issues running out of file descriptors on our consumers. 


That's usually a matter of tuning.

 

After resolving those, we were getting err=11s on searches under that entry, returning nentries=699,700,701.  700 didn’t make sense, but I thought that the issue might be the search limit – these are anonymous, so I tried the anonlimitsdn setting with a template, and set it higher than 700.  That wasn’t it. 


err=11 is usually related to either 1) look through limit 2) nsslapd-idlistscanlimit 3) unindexed searches.

 

We then started getting err=53s searching that entry – we don’t even seem to get the err=11s anymore.


What changed?  Something must have changed.  Or are you saying that for no reason, the exact same search under the exact same circumstances began returning a different result?

These searches ARE showing up un-indexed.  We have indexes for the attributes though


The indexes are related to the search filter:
filter="(&(|(objectClass=cRLDistributionPoint)(objectClass=pkiCA))(cn=CRL*8))"

In this case, the objectclass equality index, and the cn substring indexes.  Both of these are indexed by default.

So it is likely due to nsslapd-idlistscanlimit being set too low for this search.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Indexes.html#About_Indexes-Overview_of_the_Searching_Algorithm

The nsslapd-idlistscanlimit is "the configured ID list scan limit".

– is it because of the ;binary versions?


Definitely not.

 

 

Example;

 

[21/Jan/2014:13:32:28 -0500] conn=37952 op=1 SRCH base="ou=Entrust Managed Services SSP CA,ou=Certification Authorities,o=Entrust,c=US" scope=2 filter="(&(|(objectClass=cRLDistributionPoint)(objectClass=pkiCA))(cn=CRL*8))" attrs="authorityrevocationlist;binary authorityRevocationList certificaterevocationlist;binary certificateRevocationList"

 

[21/Jan/2014:13:32:28 -0500] conn=37952 op=1 RESULT err=53 tag=101 nentries=0 etime=0 notes=U

 



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users