[MB-6586] Replication rate may drop when the XDCR replication queue size becomes less than 500k items Created: 10/Sep/12  Updated: 10/Jan/13  Resolved: 28/Sep/12

Status: Closed
Project: Couchbase Server
Component/s: cross-datacenter-replication
Affects Version/s: 2.0
Fix Version/s: 2.0-beta-2
Security Level: Public

Type: Bug Priority: Critical
Reporter: Ketaki Gangal Assignee: Junyi Xie (Inactive)
Resolution: Fixed Votes: 0
Labels: 2.0-beta-release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2012-09-19 at 12.09.13 PM.png    

The replicator has a logic that if there are less than 500 items int the queue it will wait a bit (which maybe is too much) until more items shows up.
This is why the replication rate when the queue is about 600K and less is dropping.

It seems that when there are 1M items in the queue and more the replication rate is still 5-10K even if there is load on the destination.

We need to find some solution for that because that logic means that the closer the destination gets to the source, the lower the replication rate is (because there are less items on the XDCR replication queue per vbucket).

At least the good news is that the front load on the source does not have major impact on the destination.

Damien is looking at the code in question: I don't see the where the batch size would cause this slowdown. I believe this is a problem in ep-engine where it gets into a state where waking the flusher doesn't work for some reason, so it it must wait for it wake itself.

I'm going to add some code to see how long we wait for full commits to happen, vs how long we spend doing the other replication work.

Comment by Thuan Nguyen [ 11/Sep/12 ]
Integrated in github-ns-server-2-0 #465 (See [http://qa.hq.northscale.net/job/github-ns-server-2-0/465/])
    MB-6586: concurent throttle state clean up (Revision 791b42f27bea97db653a894f6cda0369da981851)

     Result = SUCCESS
pwansch :
Files :
* src/concurrency_throttle.erl
Comment by Pavel Paulau [ 18/Sep/12 ]
The issue description confused me. 500 items or 500K items?
Comment by Junyi Xie (Inactive) [ 19/Sep/12 ]
When # of items in the queue is small, the checkpointting time dominate the replication time (see screeshot). What we can do is probably to remove

1. increase the checkpoint interval and make it configurable
2. remove the last_checkpoint at the end of each turn in replicator.

Comment by Junyi Xie (Inactive) [ 20/Sep/12 ]
Commits on gerrit


Generated at Tue Jul 22 09:08:08 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.