On Thursday, 5 July 2007, Toby Blake wrote:
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.
Yes, it is probably advisable not to use only a local daemon to provide a service required by other processes that will take away resources from the daemon they rely on ...
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.
Are you using nscd ? Yes, I know the point of the local slapd is similar to that of nscd, but if you don't use nscd, each binary that does any user/group lookups will have a connection to your ldap server. Using nscd should not require any planning/investigation, just testing.
If nscd is unsuitable, you may also consider nss_db and nss_updatedb (this may require planning/investigation).
Oh, and your custom replication method looks a lot like syncrepl ...
Regards, Buchan