Shipping lucene segments during peer recovery is configured to set the transport compress options to false:
|
.withCompress(false) // lucene files are already compressed and therefore compressing this won't really help much so |
|
// we are saving the cpu for other things |
Unfortunately this is overridden when transport.tcp.compress is enabled, discarding the request-level option:
|
if (compress) { |
|
options = TransportRequestOptions.builder(options).withCompress(true).build(); |
|
} |
This means that when transport.tcp.compress is enabled, the (already compressed) Lucene files are unnecessarily compressed a second time, slowing peer recovery.
My preference would be that transport options that were explicitly set (withCompress(true) or withCompress(false)) take precedence over transport.tcp.compress.
Relates to https://discuss.elastic.co/t/elasticsearch-6-3-0-shard-recovery-is-slow/140940/
Shipping lucene segments during peer recovery is configured to set the transport compress options to false:
elasticsearch/server/src/main/java/org/elasticsearch/indices/recovery/RemoteRecoveryTargetHandler.java
Lines 70 to 71 in 7f473b6
Unfortunately this is overridden when
transport.tcp.compressis enabled, discarding the request-level option:elasticsearch/server/src/main/java/org/elasticsearch/transport/TcpTransport.java
Lines 873 to 875 in 7f473b6
This means that when
transport.tcp.compressis enabled, the (already compressed) Lucene files are unnecessarily compressed a second time, slowing peer recovery.My preference would be that transport options that were explicitly set (
withCompress(true)orwithCompress(false)) take precedence overtransport.tcp.compress.Relates to https://discuss.elastic.co/t/elasticsearch-6-3-0-shard-recovery-is-slow/140940/