Howard and all, I made more tests and looks like problem persists. I saw some changes but only in the memory consumption in "consumer(slave)" syncrepl. Let me try to explain better. I have a pair of provider/consumer machines where one machine will always receive all read/writes and the other is just for High Availability(HA) purposes, so it is better have the more close as possible the DBs. I start the provider(master) and then just after start the consumer(slave). The configuration doesn't appear to have problems since I have in my configuration 2 DBs, CONTENT and INDEX, and I see consumer doing 2 searches in these DBs when started(this is ok). After this both consumer and provider CPU usage increases so as memory allocation by slapd process. After the HEAD changes the memory consumption in consumer increases in a much more fast rate, something like 10:1. In this way to reproduce the issue I needed to reduce the dncachesize directive in consumer to 1/10 of the provider value, or from 4,000,000 to 400,000. This avoid the process to consume all memory before the issue arises. Let me try to summarize : 1) Start provider(mater) slapd process; 2) Start consumer(slave) slapd process; 3) Monitor memory and CPU usage in both provider and consumer; 4) Make sometimes a monitor check to see the cache information; 5) Before cache is full in provider(master) I made a gdb debug to check the consumer(slave) process threads; 6) Wait until the consumer(slave) process starts to use around 200% CPU and then collect again a gdb debug; 7) Wait a little more until the provider(master) CPU usage becomes 0% and then see that consumer(slave) CPU stay stable in 200%. Collect a gdb debug. 8) Wait some more time just for more gdb debug to see if something changed. I re-compile the HEAD with GDB symbols for debugging. In this way I created the file attached where more than once I collect the debug information from the consumer slapd(includes the syncrepl thread). Please see file attached for details. The item 7) is the issue I think is happening. The synchronization never ends, the responsiveness from consumer(slave) to queries is very slow, CPU usage becomes fixed in 200%, and then the logic appears never be working as expected, or in the end never synchronizing. In the end appears that syncrepl still with some issue to synchronize the DBs. Regards, Rodrigo. --- On Thu, 3/19/09, Howard Chu <hyc(a)symas.com&gt; wrote: