[Date Prev][Date Next]
Re: syncrepl and slowness during updates
--On Tuesday, December 12, 2006 12:44 PM -0800 Paul Main <firstname.lastname@example.org>
Here at UCI we have just deployed syncrepl to replicate our
LDAPdirectory. Unfortunately, we use an old directory structure
(PH/QI)for our master database, and ldap gets updates from that system
inbatch. The batch process updates our master LDAP server, andsyncrepl
is used to push the changes out to all the other LDAPservers. This
causes somewhere around 100 to 1000 entries to beupdated all at once (out
of 80k + entries in the LDAP directory).
The problem we are experiencing is that when a syncrepl slavereceives a
bunch of updates, queries to these slaves slow downtremendously. We are
talking going from a sub second query time fora single LDAP entry, to, in
some cases, over 20 seconds response timefor simple queries. This is
causing all sorts of problems for us. One thing to note: the master does
basically the same updates, butthrough an normal ldap client, rather than
through syncrepl -- and itdoes not experience this slowness.
We are using BDB, Openldap ver. 2.3.28 and our syncrepl entry
lookssomething like this:
searchbase="OU=University of California
updatedn="cn=root,OU=University of CaliforniaIrvine,
ty of California, C=US"
binddn="uid=nsp,OU=University of California
of California, C=US"
(a) interval is not valid when using refreshAndPersist. This is a very
common error, and I don't get why people make it, the man page clearly
In the refreshOnly operation, the next synchronization search operation is
rescheduled at an interval time (specified by interval
parameter; 1 day by default)
(b) Your values for sizelimit and timelimit are suspect. Per the man page:
The sizelimit and timelimit only accept "unlimited" and positive
integers, and both default to "unlimited".
(c) There's no need to specify the filter since you are using the default
In other bits, you don't provide your BDB configuration at all (i.e., what
the DB_CONFIG file has), nor do you note db size vs. memory size, cache
Principal Software Developer
ITS/Shared Application Services
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html