Couchbase Server

Adaptive parallelism in the vbucket move

Details

  • Type: Story Story
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0
  • Fix Version/s: .next
  • Component/s: ns_server
  • Security Level: Public
  • Labels:
    None

Description

It takes a couple of minutes (I didn't measure that accurate, but I would say ~10) on my machine when I try to add the second node to my cluster with 1 bucket and _NO_ items. Both of these nodes is running on the same server, and there is plenty of CPU left on the box to speed up the transfer. Given that ns_server knows the total amount of data kept in the bucket, it could move more buckets in parallel (in this case we've got 0 items, so we could most likely move all of the vbuckets it wants in parallel). As the item count and memory usage grows it should reduce the parallelism.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Aleksey Kondratenko added a comment -
Getting this off my list. IMHO too minor to spend my time in foreseeable future. And btw since 2.0.1 we already much better. And will naturally get better and better. Particularly with UPR stuff
Show
Aleksey Kondratenko added a comment - Getting this off my list. IMHO too minor to spend my time in foreseeable future. And btw since 2.0.1 we already much better. And will naturally get better and better. Particularly with UPR stuff
Hide
Permalink
Dipti Borkar added a comment -
Aliaksey, even with 2.0.1 though we are still transferring 1 vBucket at a time if there's 1 node being added right?

the speed improvement is mostly from combining compaction of vBuckets ?
Show
Dipti Borkar added a comment - Aliaksey, even with 2.0.1 though we are still transferring 1 vBucket at a time if there's 1 node being added right? the speed improvement is mostly from combining compaction of vBuckets ?
Hide
Permalink
Aleksey Kondratenko added a comment -
Not only that. 2.0.1 fulfills 1 vbucket at a time limit only for duration backfill. When we detect that backfill is done or did not happen we immediately start next vbucket. Then after 16 vbuckets (which we're about to rise, btw I completely forgot and we _have to_ do it before 2.0.2 is frozen) are moved we wait until all vbucket movements complete. And that per vbucket completion involves all that dance with checkpoints and waiting for disk that we do.

It'll be a bit premature to say that 1 vbucket at a time is a bottleneck with that new behavior.
Show
Aleksey Kondratenko added a comment - Not only that. 2.0.1 fulfills 1 vbucket at a time limit only for duration backfill. When we detect that backfill is done or did not happen we immediately start next vbucket. Then after 16 vbuckets (which we're about to rise, btw I completely forgot and we _have to_ do it before 2.0.2 is frozen) are moved we wait until all vbucket movements complete. And that per vbucket completion involves all that dance with checkpoints and waiting for disk that we do. It'll be a bit premature to say that 1 vbucket at a time is a bottleneck with that new behavior.

People

  • Assignee:
    Dipti Borkar
    Reporter:
    Trond Norbye
Vote (0)
Watch (2)

Dates

  • Created:
    Updated: