[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Lock is no longer valid / deferring operation
<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
>