Re: (ITS#5664) Deadlocks when writing in parallell (two processes)

[quanah@zimbra.com]

--On Thursday, August 21, 2008 6:29 PM +0000 hyc@symas.com wrote:

> stelios.xx.grigoriadis@ericsson.com wrote:
>> tom.bjorkholm@aastra.com wrote:
>>> Full_Name: Stelios Grigoriadis&  Tom Bj?rkholm
>>> Version: 2.3.39
>>> OS: Novell SLES 10
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (194.237.142.7)
>>>
>>>
>>> We get a lot of DB_LOCK_DEADLOCK when using client programs that for a
>>> period of time continuously writes to OpenLDAP.
>>> Version is 2.3.39.
>>>
>>> The information added is of the form:
>>> ebcmdCustomer=0+ebcmdDir=220xx,ou=AuthCodes,ebcmdVersion=0,ebcmdProduct
>>> =ebcmd,dc=example,dc=com where xx varies.
>>>
>>> Snippet of the output:
>>> Mar 27 13:03:21 ldapt1 slapd[7589]: =>  bdb_dn2id_add: subtree
>>> (ebcmdCustomer=0+ebcmdDir=22037,ou=authcodes,ebcmdVersion=0,ebcmdProduc
>>> t=ebcmd,dc=example,dc=com) put failed: -30995
>>> Mar 27 13:03:26 ldapt1 slapd[7589]: =>  bdb_idl_insert_key: c_put id
>>> failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995)
>>> Mar 27 13:03:26 ldapt1 slapd[7589]: =>  bdb_dn2id_add: parent
>>> (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com)
>>> insert failed: -30995
>>> Mar 27 13:03:28 ldapt1 slapd[7589]: =>  bdb_idl_insert_key: c_put id
>>> failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995)
>>> Mar 27 13:03:28 ldapt1 slapd[7589]: =>  bdb_dn2id_add: parent
>>> (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com)
>>> insert failed: -30995
>>> Mar 27 13:03:36 ldapt1 slapd[7589]: =>  bdb_idl_insert_key: c_put id
>>> failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995)
>>> Mar 27 13:03:36 ldapt1 slapd[7589]: =>  bdb_dn2id_add: parent
>>> (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com)
>>> insert failed: -30995
>>> Mar 27 13:03:38 ldapt1 slapd[7589]: =>  bdb_idl_insert_key: c_put id
>>> failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995)
>>>
>>>
>>>
>>
>> We've temporarily fixed the problem by introducing a static mutex before
>> any add/update operation.
>
> There's no problem to fix. Deadlocks are normal in these scenarios, and
> the  code automatically retries. This ITS will be closed.

I will note that testing on 2.3 has shown time and again that serialized 
updates perform better, regardless.  Using accesslog with delta-syncrepl 
replication essentially enforces this.  The more you can serialize updates, 
particularly with batch provisioning, the smoother your system will 
operate.  This may not apply to 2.4.

--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration