[Date Prev][Date Next]
search blocks modify -- why?
Today I had a problem in which a search from one connection seemed to hang
up a modify operation on another connection.
Our directory is quite large, in excess of 500,000 entries. Currently on
OpenLDAP 2.0.27. Generally it performs very well IMO. What I observed
was a search taking place with a filter that involved a wildcard match on
an unindexed attribute. No way around it that would be slow.
At the same time, a modify operation on another connection seemed to be
blocked. When I killed the offending search query, the modify completed.
So I'd like to be clear on a couple of things:
- Can a search on one connection block a modify on another connection, due
to database locking that may be going on.
- Can the dbnolocking or dbnosync directives alter this behavior? I
understand from the man page that dbnolocking specifies "that no
database locking should be performed" but it's not clear to me when is
locking performed by default?
Other things to consider? I'm working on getting a slave server in place
so I can offload most searching activity to that machine.