<quote who="Toby Blake"> > Hi again Gavin, > > <most stuff snipped> > >>> As for what services they provide, general desktop services, but also >>> could be running long-running or intensive jobs. Many of the machines >>> are also in a condor pool and this does seem to cause more problems. >>> >>> Do you know if slapd gets unhappy if other processes use up lots of >>> memory? This is my current line of investigation - I'll try to make >>> it unhappy by using increasing amounts of memory. >> >> Yes. >> >>> >>> I suppose what I'm trying to determine is - is it the client activity >>> that's causing problems (i.e. a misbehaving client or similar) or is >>> it slapd itself getting unhappy for other reasons (possibly due to >>> resources being used by other programs)? Or a combination of both? >> >> Probably both. If a client keeps sending lots of bind/search requests at >> once, slapd will queue/defer them. > > Excellent, this does look to be the case. I've just run a bit of a > test by eating up all memory and swap and seeing if I could upset > slapd - it seemed OK for a while, then a full search of the directory > triggered off a "Lock is no longer valid" and it's now distinctly > unhappy. So, a client that not only eats memory, but also uses up > other resources, to the detriment of slapd, can only produce > problems.
Agreed. > > I suppose the way forward is to migrate away from running local slapd > everywhere, perhaps to a proxy-caching type of solution, but this is > going to require some proper planning and investigation. Yes. Feel free to run your plans via the list. > > Again, thanks for your help. np. > > Cheers > Toby >
