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

Re: slow or inconsistent syncrepl

>>That depends entirely on the speed of your server and network. 

Taking the server part first - I'm also doubt that my provider server is underpowered. 

Following are the ldap specific parameters on our provider server : 

entries : 0.5 million 
avg entry size : 1k to 4k 
cachesize : 0.5 million 
dncachesize : 0.5 million 
database type : bdb 
bdb cachesize : 3 gb 
ldap threads : 16 

Foll is hardware configuration of the provider server : 
ram : 8gb 
swap : 8gb 
cpu :  Virtual machine with 4 cpus. (vmware vsphere) 
architecture : 64 bit 

Also we have some administrative services/tasks running on the provider server other than openldap. But the sar output seems normal i.e iowait below 10 and idle time above 50. 

Does the hardware configuration seem ok for the given ldap size and configuration ? 
If not, can u suggest some changes?

Thanks and Regards,
Amol Kulkarni.


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

From: Howard Chu

Sent: 03/10/12 01:29 PM

To: Amol Kulkarni

Subject: Re: slow or inconsistent syncrepl

Amol Kulkarni wrote: 
> Dear Quanah, 
> Thanks a lot for these 2 pointers. I'll check out the 2.4.30 version. 
> We had used delta syncrepl earlier but our accesslog size used to grow 
> suddenly sometimes and the disk used to get full crashing/hanging the ldap 
> service itself on the provider. But at that time we had kept the max age for 
> the accesslog to be 7 days. I'll reduce it and give it a try again. 
> Also it would be helpful if you can throw some light on : 
> 2. On a really busy ldap server, can replication slow down drastically? i.e 
> does the read operations affect the replication in any way? 

Syncrepl executes as an LDAP Search operation, so of course it competes for 
server resources with other Search activity on the server. 

> 4. We are currently having about 60 consumers - is this too much ? What can be 
> the max numbers of consumers ? 

That depends entirely on the speed of your server and network. If you're 
seeing that replication speed is inconsistent, you probably should reduce the 
load on the provider. A simple approach in your scenario would be to just 
point the 10 consumers on the fast LAN at the provider, and configure these 
consumers to act as providers for your WAN nodes (i.e., cascaded replication). 

> 5. Sometimes we urgently need some particular node to be present on the 
> consumer - for which we cannot wait - in that case we get ldif of that node 
> from provider and do ldapadd on the consumer ( mirrormode is ON on the 
> consumers ). Is this safe and correct or could it cause some side effects ? Is 
> there a better way to handle it? 

If you have configured distinct serverIDs for each consumer, this might work. 
Otherwise, no, not safe, not correct. 

Fix your configuration layout, or fix your apps. If your apps can't wait then 
they are mis-designed; there is no such thing as instantaneous propagation of 
information in the real world. 

> Thanks and Regards, 
> Amol Kulkarni. 
>> ----- Original Message ----- 
>> From: Quanah Gibson-Mount 
>> Sent: 03/09/12 11:57 PM 
>> To: Amol Kulkarni, openldap-technical@openldap.org 
>> Subject: Re: slow or inconsistent syncrepl 
>> --On Friday, March 09, 2012 2:20 PM +0100 Amol Kulkarni 
>> <amolkulkarni@gmx.com>  wrote: 
>> >  I have a following openldap setup with syncrepl : 
>> >   - openldap version 2.4.23 
>> This is your #1 issue. 
>> >   - 1 provider and about 10 consumers in lan and 50 consumers on wan 
>> This is your #2 issue. 
>> Upgrade to a stable release.  Use delta-syncrepl, which uses significantly 
>> less bandwidth than syncrepl. 
>> --Quanah 
>> -- 
>> 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/