Re: Searches with dereferncing causing high CPU load.

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

On Tue, Nov 17, 2015 at 11:11:04AM +0000, Mark Cairney wrote:

> Just as an update- we've managed to restore service. It turns out that
> we had went over the value of 65,535 (66,291) aliases which we think was
> the root cause of this behaviour suddenly starting.

It's a significant number certainly...

> Although it relates to MDB this ITS sounded very similar:
> http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8146;page=10
> 
> We started deleting as many aliases as we could but performance only
> improved slightly. What appears to have fixed it was doing a slapcat of
> the "pruned" data and re-loading it into the database via slapadd.
> Having done this searches with deref set to always are now performing as
> they were before.

If this happens again, you could try stopping the server and running
slapindex rather than reloading everything.

> Ultimately we've been wanting to move away from both a) hdb and b)
> aliases for a while but one of our user bases runs a web application
> that requires them as it doesn't support either groups or modifying it's
> search filter. Given this incident there might be a push for them to
> re-evaluate this approach.

That does sound like a problematic app. There may be other ways of
solving the problem if you have to keep it though. I would tend to look
at having a separate instance of slapd to service it, and it might then
be possible to use mapping overlays to build a view of your data that it
can cope with. Does the app need to modify LDAP data or is it read-only?

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------