[Date Prev][Date Next]
Re: slow cn=config changes; Re: Correct procedure to backup LDAP?
On Mon, 14 Aug 2006, Howard Chu wrote:
Howard Chu wrote:
This sounds pretty normal. When you issue a modify on cn=config, it suspends
the thread pool. That means that no new operations can start, and cn=config
waits for any currently running operations to finish, then it does the
modification you requested. The busier the server, the longer you have to
wait before that modification can execute.
Ah, this explains a lot. I suppose it could be a pretty long wait if
someone were doing a particularly onerous search. Maybe the real answer
is to get the server out of the load-balancer rotation first, though that
kind of shoots down the idea of being able to quiesce the service
completely locally without interruptions.
In response to Aaron, yes, I'm trying to find the best way to get a good
point-in-time snapshot because that is the easiest thing to convey to the
various automated sources of updates. My preference would be to take
backups from a slave instance, but I just can't finagle the resources to
do it, even a trimmed no-indexes case. I like the accesslog ideas,
though. That could be handy.
I should note that for this specific example, you can also set readonly mode
using cn=monitor, which has no particular impact on the thread pool, so it
should take effect immediately.
Okay, that I don't understand. Are you still talking about putting the
hdb database in readonly mode? You can do that from cn=monitor?
Apparently I'm not up on my cn=monitor lore... that sounds like the magic
bullet. Can you give an example?
Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342