Tiered merge policy settings not documented in 2.x: gone?

(Luke Nezda) #1

index.merge.policy.segments_per_tier and related tiered merge policy settings are in https://www.elastic.co/guide/en/elasticsearch/reference/1.7/index-modules-merge.html#policy but not https://www.elastic.co/guide/en/elasticsearch/reference/2.0/index-modules-merge.html#policy . I saw some merge settings were dropped in 2.0 (https://www.elastic.co/guide/en/elasticsearch/reference/2.0/breaking_20_setting_changes.html#_merge_and_merge_throttling_settings). Were all these dropped?

Kind regards,

  • Luke

(Mark Walkom) #2

Merging is now automatically handled, so yes, they are no longer configurable.

(Luke Nezda) #3

In Tuning indices.memory.max_index_buffer_size for indexing throughput I'm trying to figure out why one of my test indices had only 54 merges (vs. at least 400 usually) and dramatically less total indexing and merging time (but I believe the basically the same indexed content). (I have the detailed stats - I'll put them at the end). Maybe the automatic merge policy behaved differently for that run? Each next-iteration index we create is write-only (I.e., not being searched) until it is complete and I'd like to exploit that and those merge policy settings seemed very promising. I've tried increasing translog to 1g, increased memory buffer from 10% to 25%, decreasing client indexing concurrency, and increased throttle to 100mb, but still haven't reproduced my very fast indexing run. Any tips/ideas?

Kind regards,

  • Luke

Silly fast? https://gist.github.com/nezda/0f19cc7db0d1d4850823420d467b8899

  • docs.count : 37617976
  • .store.throttle_time_in_millis : 244767 (0.07 CPU hours)
  • .indexing.throttle_time_in_millis : 0
  • .indexing.index_time_in_millis 625739 (0.17 CPU hours)
  • .merges.total_time_in_millis 2608960 (0.72 CPU hours)

What I'm used to despite tuning efforts: https://gist.github.com/nezda/0a0de0a154483ee2faedea57284d8767

  • docs.count : 41964664 (11% more?)
  • .store.throttle_time_in_millis : 1245458 (0.34 CPU hours)
  • .indexing.throttle_time_in_millis : 1188
  • .indexing.index_time_in_millis 73444347 (20 CPU hours)
  • .merges.total_time_in_millis 28774143 (8 CPU hours)

(system) #4