Ok, I have been running 2.4.32 for some time with no issues. Yesterday, 2 different servers (both part of a 4-way MMR) produced an &quot;index add failure&quot; and an &quot;index delete failure&quot;. I went back over the bdb DB_CONFIG Settings (listed below) and everything looks nominal to me. Would it just make more sense to switch from bdb to mdb instead of troubleshooting these &quot;random&quot; errors too much? I also noticed that the number of &quot;deadlocks&quot; corresponds to the number of errors that were produced. Is there correlation there?<div>
<br></div><div>Thanks!<br><div><br></div><div><br></div><div><div>578     Last allocated locker ID</div><div>0x7fffffff      Current maximum unused locker ID</div><div>9       Number of lock modes</div><div>3000    Maximum number of locks possible</div>
<div>1500    Maximum number of lockers possible</div><div>1500    Maximum number of lock objects possible</div><div>1       Number of lock object partitions</div><div>15      Number of current locks</div><div>1029    Maximum number of locks at any one time</div>
<div>17      Maximum number of locks in any one bucket</div><div>0       Maximum number of locks stolen by for an empty partition</div><div>0       Maximum number of locks stolen for any one partition</div><div>123     Number of current lockers</div>
<div>224     Maximum number of lockers at any one time</div><div>15      Number of current lock objects</div><div>526     Maximum number of lock objects at any one time</div><div>5       Maximum number of lock objects in any one bucket</div>
<div>0       Maximum number of objects stolen by for an empty partition</div><div>0       Maximum number of objects stolen for any one partition</div><div>3581M   Total number of locks requested (3581768929)</div><div>3581M   Total number of locks released (3581768869)</div>
<div>0       Total number of locks upgraded</div><div>77      Total number of locks downgraded</div><div>7041    Lock requests not available due to conflicts, for which we waited</div><div>43      Lock requests not available due to conflicts, for which we did not wait</div>
<div>2       Number of deadlocks</div><div>0       Lock timeout value</div><div>0       Number of locks that have timed out</div><div>0       Transaction timeout value</div><div>0       Number of transactions that have timed out</div>
<div>1MB 392KB       The size of the lock region</div><div>0       The number of partition locks that required waiting (0%)</div><div>0       The maximum number of times any partition lock was waited for (0%)</div><div>0       The number of object queue operations that required waiting (0%)</div>
<div>577     The number of locker allocations that required waiting (0%)</div><div>32148   The number of region locks that required waiting (0%)</div><div>5       Maximum hash bucket length</div><div><br></div><br><div class="gmail_quote">
On Wed, Aug 29, 2012 at 12:04 PM, Quanah Gibson-Mount <span dir="ltr">&lt;<a href="mailto:quanah@zimbra.com" target="_blank">quanah@zimbra.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">--On Wednesday, August 29, 2012 11:32 AM -0400 Kyle Smith &lt;<a href="mailto:alacer.cogitatus@gmail.com" target="_blank">alacer.cogitatus@gmail.com</a>&gt; wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Quanah, Thanks for the info, I have confirmed I&#39;m hitting the lock maxes<br>
of 1000. And I will be upgrading to 2.4.32. I was wondering, what steps<br>
should be done to have the changes in DB_CONFIG take effect?<br>
<br>
<br>
stop slapd<br>
make changes to DB_CONFIG<br>
db_recover<br>
start slapd<br>
<br>
<br>
Will this also auto remove the log.* files? ( I plan on setting this:<br>
&quot;set_flags DB_LOG_AUTOREMOVE&quot; in DB_CONFIG)<br>
</blockquote>
<br></div>
If you have checkpointing set in slapd.conf/cn=config, it should, yes.<span class="HOEnZb"><font color="#888888"><br>
<br>
--Quanah</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
<br>
Quanah Gibson-Mount<br>
Sr. Member of Technical Staff<br>
Zimbra, Inc<br>
A Division of VMware, Inc.<br>
--------------------<br>
Zimbra ::  the leader in open source messaging and collaboration<br>
</div></div></blockquote></div><br></div></div>