Re: Searches with dereferncing causing high CPU load.
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 |
-----------------------------------------------------------------------