You should check index.shard.recovery.concurrent_streams which is default to 5 per node.
If you have 3500 indices, but only so few data volume, you can turn up this value very high, and your recovery will be lightning fast. But, the default value was considered carefully, so a high load of queries always has precedence over the recovery in the background, so queries do not time out that easily. Both user comfort and admin patience must be well balanced. Jörg On Wed, Feb 12, 2014 at 10:36 PM, Tony Su <[email protected]> wrote: > Josh, > > Your experience about recovering in only about 10 minutes is very > interesting. > Because my little 5-node cluster/15GB data/3500 indices is taking about an > hour to recover and i know the bottleneck is the disk subsystem I'm > currently on, > > Am curious > - What is the total size data in your cluster? > - how many indices? > - Are the shard numbers pretty typical (5 shards per index, 1 replica for > every shard) > - Are you storing your data on a SAN, SCSI array or something else, and if > the disks are SSD? > > Thx, > Tony > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/26b49ca2-31a3-4800-8d76-16c6ea405c8a%40googlegroups.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGk0KkjBCPcuObbgn%2BvN5VoVcGg5R_RJFyB41Std6K%3DSA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
