ilm-forcemerge.asciidoc 2.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081
  1. [role="xpack"]
  2. [[ilm-forcemerge]]
  3. === Force merge
  4. Phases allowed: hot, warm.
  5. <<indices-forcemerge,Force merges>> the index into
  6. the specified maximum number of <<indices-segments,segments>>.
  7. This action makes the index <<dynamic-index-settings,read-only>>.
  8. [NOTE]
  9. The `forcemerge` action is best effort. It might happen that some of the
  10. shards are relocating, in which case they will not be merged.
  11. To use the `forcemerge` action in the `hot` phase, the `rollover` action *must* be present.
  12. If no rollover action is configured, {ilm-init} will reject the policy.
  13. [[ilm-forcemerge-performance]]
  14. .Performance considerations
  15. ****
  16. Force merge is a resource-intensive operation.
  17. If too many force merges are triggered at once, it can negatively impact your cluster.
  18. This can happen when you apply an {ilm-init} policy that includes a force merge action
  19. to existing indices.
  20. If they meet the `min_age` criteria, they can immediately proceed through multiple phases.
  21. You can prevent this by increasing the `min_age` or setting `index.lifecycle.origination_date`
  22. to change how the index age is calculated.
  23. If you experience a force merge task queue backlog,
  24. you might need to increase the size of the force merge threadpool so
  25. indices can be force merged in parallel.
  26. To do this, configure the `thread_pool.force_merge.size` <<cluster-get-settings,cluster setting>>.
  27. IMPORTANT: This can have cascading performance impacts.
  28. Monitor cluster performance and increment the size of the thread pool slowly to reduce the backlog.
  29. Force merging will be performed by the nodes within the current phase of the index. A forcemerge in
  30. the `hot` phase will use hot nodes with potentially faster nodes, while impacting ingestion more. A
  31. forcemerge in the `warm` phase will use warm nodes and potentially take longer to perform, but
  32. without impacting ingestion in the `hot` tier.
  33. ****
  34. [[ilm-forcemerge-options]]
  35. ==== Options
  36. `max_num_segments`::
  37. (Required, integer)
  38. Number of segments to merge to. To fully merge the index, set to `1`.
  39. `index_codec`::
  40. (Optional, string)
  41. Codec used to compress the document store. The only accepted value is
  42. `best_compression`, which uses {wikipedia}/DEFLATE[DEFLATE] for a higher
  43. compression ratio but slower stored fields performance. To use the default LZ4
  44. codec, omit this argument.
  45. +
  46. WARNING: If using `best_compression`, {ilm-init} will <<indices-close,close>>
  47. and then <<indices-open-close,re-open>> the index prior to the force merge.
  48. While closed, the index will be unavailable for read or write operations.
  49. [[ilm-forcemerge-action-ex]]
  50. ==== Example
  51. [source,console]
  52. --------------------------------------------------
  53. PUT _ilm/policy/my_policy
  54. {
  55. "policy": {
  56. "phases": {
  57. "warm": {
  58. "actions": {
  59. "forcemerge" : {
  60. "max_num_segments": 1
  61. }
  62. }
  63. }
  64. }
  65. }
  66. }
  67. --------------------------------------------------