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 | -----------------------------------------------------------------------
