slices

This setting can speed up reindexing operations by using Sliced Scroll to slice on the _uid.

actions:
  1:
    description: "Reindex index1,index2,index3 into new_index"
    action: reindex
    options:
      wait_interval: 9
      max_wait: -1
      slices: 3
      request_body:
        source:
          index: ['index1', 'index2', 'index3']
        dest:
          index: new_index
    filters:
    - filtertype: none

Here are a few recommendations around the number of slices to use:

• Don’t use large numbers. 500 creates fairly massive CPU thrash, so Curator will not allow a number larger than this.
• It is more efficient from a query performance standpoint to use some multiple of the number of shards in the source index.
• Using exactly as many shards as are in the source index is the most efficient from a query performance standpoint.
• Indexing performance should scale linearly across available resources with the number of slices.
• Whether indexing or query performance dominates that process depends on lots of factors like the documents being reindexed and the cluster doing the reindexing.