Re: back-bdb performance

[Marijn Meijles <marijn@bitpit.net>]

You wrote:
> 
> If you'd care to give me some hints about what you saw in the update
> order, I'm open.
	
Ok, I've looked at the latest cvs version of back-bdb/add.c and it's
clear why you get so much deadlocks. The problem is that you look up the parent
WITH the transaction, thereby rlocking the parents page. You see, the whole
bottleneck are the parents db entries, because in most ldap cases concurrent
adds share the parent. So (in the ideal case) you should:
- lookup the parent with a null txn
- defer parent updates (think old school id2children if you will) as long
as you can. That way you minimize the time you hold a lock on the parent
(the time between update and commit)

However, I don't think this will work in your case, because you don't have
an entry cache which can protect the parent from being changed during an add,
therefore you need the parent read to be within the transaction.

As for the child txn, I use one to encapsulate the parent updates. That
doesn't hurt throughput and reduces the retry time. Although I might drop it again
as I went from 3000 to 5 deadlocks during a concurrent add of 2x5000 entries.

-- 
Marijn@bitpit.net
---
The light at the end of a tunnel may be an oncoming train.