[Date Prev][Date Next]
Re: concurrent access on LDBM backend
The LDBM backend works with a so-called "giant rw lock" which means you can
have multiple "readers" doing LDBM operations in parallel, but you can't have
multiple "readers" and "writers" or multiple "writers" doing parallel LDBM
operations. The rw lock is on a high level with the LDBM backend which means
that if the LDBM backend has to perform a complex modify or add operation
with multiple index databases involved, it locks other "writers" and
"readers" for the time of the operation.
You can gain performance by trying to reduce the amount of (expensive) indexes
or attributes and thus make the impact of add/modify operations smaller.
On Tuesday 15 July 2003 16:53, Paternoster Sergio wrote:
> Hi all,
> I run a 2.0.27 OpenLDAP version on 3.3 BerkeleyDB (back-ldbm) on Solaris 8.
> I have heavy indexes that slows the writes (also dbnosync disabled on
> masters/slaves). Could threads help searches on slaves? If the slurpd is
> replicating to my slaves, the heavy indexes slow down the write process. I
> heard that when a thread is writing to the LDBM backend it will block all
> other threads from accessing the LDBM backend. As a write is currently
> taking a long time (due to index maintenance), the searches are not being
> handled by the other threads. Is it true? The heavy writes stop reads?
> Thanx in advance
> Sergio Paternoster