[Date Prev][Date Next]
Re: syncrepl consumer is slow
Hallvard Breien Furuseth wrote:
Another option here is simply to perform batching. Now that we have the
TXN api exposed in the backend interface, we could just batch up e.g.
500 entries per txn. much like slapadd -q already does. Ultimately we
ought to be able to get syncrepl refresh to occur at nearly the same
speed as slapadd -q.
On 29. jan. 2015 04:12, Howard Chu wrote:
I'm considering adding an option to the consumer to write its entries
dbnosync during the refresh phase. The rationale being, there's
lose anyway if the refresh is interrupted. I.e., the consumer can't
its contextCSN until the very end of the refresh, so any partial
gets interrupted is wasted effort - the consumer will always have to
over from the beginning on its next refresh attempt.
dbnosync loses consistency after a system crash, and it loses the knowledge
that the DB may be inconsistent. At least with back-mdb. The safe thing
to do after such a crash is to throw away the DB and fetch the entire thing
from the provider. Which I gather would need to happen automatically
with such an option.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/