Re: concurrent access on LDBM backend

[Erik <edg72@home.nl>]

Sergio,

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.

Regards,

Erik


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
>
> regards
>
> Sergio Paternoster