Looks like enabling tcp compression actually slows down the transfer rate of shards. Setting this I'm basically stuck to 13Mbs even though I've set the max_bytes_per_sec to -1 This has led to it taking about 1.2h to transfer a 50GB shard when it used to take 36m. Is there any thing we can do to get around this? is the max_bytes_per_sec setting not respected if we use compression? On a large cluster in AWS this helps to save a bunch of money on transfer costs, but it kind of is disappointing to see such a slow transfer rate. Important to note that the CPU isn't doing anything so I wouldn't think it was restricted by that.
What version of Elasticsearch are you using? This might be helpful if your running 6x slow 6x shard recovery Only way I was able to attain configured max_bytes_per_sec was to disable compression, this was due to the change in concurrency between versions. If your running a different version then adjusting settings may help you with shard recovery/relocation time with compression enabled, specifically indices.recovery.concurrent_streams
Yea, looks like compression does a double compress on recovery. There's a github issue about this. Guess I'll just disable it for now and pay the bandwidth costs 
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.