Transport.tcp.compress slowing down shard relocation

(Djtecha) #1

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.

(Curtis Luce) #2

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

(Djtecha) #3

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 :frowning:

(system) #4

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.