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

Re: slow or inconsistent syncrepl

Amol Kulkarni wrote:
As per the recommendations, we have done following :
1. Installed openldap 2.4.30 on master & all replicas.
2. We have cascaded the replication by adding another replica in lan which
acts as provider for the consumers on wan.

There are definite improvements but still we are observing following problem :

1. Bulk changes (1000 records changed) in LDAP on the provider, do not
replicate to replicas with busy ldap unless
a) the records are updated in smaller batches on provider
b) the replication database on the consumer is reset - i.e ldap restarted with
-c rid=001

Neither of those options should be necessary.

Is there a buffer/queue at the consumer side which overflows?

No, there is nothing that overflows.

Can it be tuned?
Does a busy server drop replication requests?

No, requests are not dropped.

But a syncrepl consumer runs as a task in the slapd thread pool. If the server is already busy with other requests, it may be a long time before a thread frees up to handle replication traffic. You might be able to improve things by configuring more threads in slapd, but that will only go so far. If all of the server's CPUs are already busy, there's nothing else to do besides get faster servers or add more replicas.


----- Original Message -----

From: Quanah Gibson-Mount

Sent: 03/12/12 03:36 AM

To: Amol Kulkarni

Subject: Re: slow or inconsistent syncrepl

--On Sunday, March 11, 2012 8:51 AM +0100 Amol Kulkarni
<amolkulkarni@gmx.com>  wrote:

>  I see that I'm outdated in my tuning as per
>  http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning.
>   I'll do these changes and observe the servers.
>  In the mean time a new observation regarding syncrepl is that if I do
>  ldapmodify for 5 - 10 entries in one go the changes get replicated but if
>  I change about 300 entries in one go, then some entries do not get
>  replicated on some servers. These changes dont get replicated until I
>  change those entries again.
>  Does this indicate provider resource problem or consumer resource problem
>  ( or normal behaviour ) ?

Changes failing to replicate is not a desired behavior.  It is expected to
occur in older known buggy releases.  If all of your masters&  replicas are
on 2.4.30, hopefully you won't see that issue any more.



Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
Zimbra ::  the leader in open source messaging and collaboration

  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/