Screen Shot 2012-09-19 at 12.09.13 PM.png
[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 |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | 2.0-beta-release-notes | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
Screen Shot 2012-09-19 at 12.09.13 PM.png
|
| Description |
|
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. |
| Comments |
| 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/]) 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 [ 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 [ 20/Sep/12 ] |
|
Commits on gerrit
http://review.couchbase.org/#/c/20972/ http://review.couchbase.org/#/c/20967/ |