[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Delta-syncrepl and latency

--On Tuesday, May 08, 2007 8:50 PM -0400 Sam Tran <stlist@gmail.com> wrote:

Hi All,

I am testing delta-syncrepl using OpenLDAP 2.3.35 (+ fixes ITS#4924
and fixes ITS#4925) and Berkeley DB 4.5.20 on Centos 5.

I have a provider with the following configuration:

# -------------------------------------------------
# Accesslog DB definition (slapo-accesslog)
# -------------------------------------------------
# Access logging overlay

database        hdb
suffix          "cn=accesslog"
rootdn          "cn=root,cn=accesslog"
directory       /var/lib/ldap/accesslog
index           default eq
index           entryUUID,entryCSN,objectClass,reqEnd,reqResult,reqStart

# Let the replica DN have limitless searches
limits dn.exact="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com
time.soft=unlimited time.hard=unlimited size.soft=unlimited
size.hard=unlimited

# -------------------------------------------------
# End of Accesslog DB definition (slapo-accesslog)
# -------------------------------------------------

# Syncrepl overlay - Provider configuration for suffix "cn=accesslog"
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE

# -------------------------------------------------
# Primary database definition
# -------------------------------------------------

database        hdb
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,dc=com"
rootpw          secret
directory       /var/lib/ldap/example.com
cachesize       5000
idlcachesize    2000
checkpoint      512     10

index   objectClass,uidNumber,gidNumber,memberUid,employeeNumber eq,pres
index
employeeType,accountActive,ftpActive,mailActive,vacationActive,ou,mailRou
tingAddress
eq
index   cn,mail,surname,givenname eq,pres,subinitial
index   displayName,gecos,telephoneNumber sub,subany
index   uid,aliasUid eq,sub,subany
index   entryUUID,entryCSN eq

# Let the replica DN have limitless searches
limits dn.exact="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com"
time.soft=unlimited time.hard=unlimited size.soft=unlimited
size.hard=unlimited
# -------------------------------------------------
# End of primary database definition
# -------------------------------------------------

# Syncrepl - Provider configuration
overlay syncprov
syncprov-checkpoint 100 30
syncprov-sessionlog 100

# Access Logging overlay
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
logpurge 28+00:00 01+00:00


Here is the configuration of the consumer:

#############################################################
# Syncrepl - Consumer configuration
#############################################################
syncrepl        rid=006
                provider=ldaps://provider.example.com:636
                bindmethod=simple
                binddn="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com"
                credentials=secret
                type=refreshAndPersist
                retry="5 +"
                searchbase="dc=example,dc=com"
                logbase="cn=accesslog"
                logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
                schemachecking=on
                syncdata=accesslog

I've been running some LDAP writes (batches of 10 to 10000 sequential
writes) on the provider to test the replication on the consumer.
Sometimes I observed some latency up to 35 sec. on the consumer with
the following messages in the logs:
May  8 16:52:08 info-ldap-006 slapd[24480]: do_syncrep2: rid 006 Can't
contact LDAP server
May  8 16:52:08 info-ldap-006 slapd[24480]: do_syncrepl: rid 006 retrying

Some other times, there was not replication at all until I restarted
the consumer.

Am I missing something in the configuration? Please could you shed
some light on the matter?


How have you tuned DB_CONFIG for the accesslog backend?

--Quanah


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