[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: FW: slapd threads on master pegs multiple CPU Sun running Solaris 8 (ITS#2302)

One possible approach is not to wrap the whole search operation
in a single transactions, but use many.  One for baseObject
finding, one for candidate determination, and one for each
candidate.  However, this would likely cost way more than 10%
(with logging).


At 04:11 PM 2/14/2003, Howard Chu wrote:
>I guess it's worth exploring. It might be nice if BDB provided a locker
>entity for this purpose - i.e., like a transaction, all locks are held by one
>locker, but without any of the logging associated with a real transaction. I
>haven't convinced myself yet that it really buys us much.
>In the normal case, you slow down the search by 10% and get no other benefit.
>In the case of multiple concurrent operations, you actually decrease
>concurrency because locks obtained inside a transaction are held to the end
>of the transaction, no matter if you explicitly release them or not.
>In the case of a search spawned while processing another transaction, you are
>creating nested transactions, which decreases concurrency even fruther
>because all of the locks in each nested transaction are held until the parent
>is released. If you don't nest the transactions, then you're just as
>vulnerable to deadlock as before.
>The deadlock problem seems to arise from the fact that we can either use
>transactions, in which case all locks are tied to that one transaction (this
>is good because it prevents us from deadlocking ourself, bad because it keeps
>locks longer than they're needed) or we have every individual operation
>getting/releasing its own locks on the fly (bad because we can deadlock
>ourself easily). What would be ideal is something in the middle - passing a
>locker ID to every BDB function, so that it gets used for all the locks, and
>they are all released at the exact moment we wish.
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support
>-----Original Message-----
>From: owner-openldap-bugs@OpenLDAP.org
>[mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of jongchoi@us.ibm.com
>I think we should restart discussing on the transaction-protected searches.
>The overhead of transactional searches does not seem to be prohibitively
>(I remember around 10% when I experimented with it.)
>One concern is the semantics of the aborted LDAP search.
>1. abort the whole search ?
>    In this case, it would be the client's responsibility to resend the
>search request.
>2. abort a single db->get() of the candidate loop ?
>   We should have one transaction per loop iteration.
>   The overhead of frequent transaction begin and commit has to be
>- Jong
>BTW, Joseph, what is the version number of BerkeleyDB ? Is it 3.x ?
>Jong Hyuk Choi
>IBM Thomas J. Watson Research Center - Enterprise Linux Group
>P. O. Box 218, Yorktown Heights, NY 10598
>email: jongchoi@us.ibm.com
>(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979