【ELK】ElasticSearch 合并segments

勤不了一点

已于 2024-04-03 10:43:35 修改

阅读量567

点赞数 7

分类专栏： ElasticStack 文章标签： elk elasticsearch

于 2024-04-03 10:42:35 首次发布

本文链接：https://blog.csdn.net/qq_56676115/article/details/137333605

版权

ElasticStack 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

segments相关优点与注意事项

https://www.elastic.co/guide/en/elasticsearch/reference/7.17/ilm-forcemerge.html
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/indices-forcemerge.html#forcemerge-blocks
https://opster.com/guides/elasticsearch/operations/force-merge-operations/

优点：

优化索引性能和管理存储空间，以减少索引文件的数量、提高查询性能,从而提高搜索速度并释放磁盘空间

强制合并注意事项：

Merge是一项资源密集型操作，如果一次触发太多强制合并，可能会对您的集群产生负面影响。
只读索引：需要在已完成写入的索引进行合并（cold 或者只读索引），强制合并可以提高搜索性能并减少磁盘使用量。
基于时间的索引：对于基于时间序列（例如日志或事件数据）的索引，强制合并旧索引可能是有益的。
磁盘空间管理：强制合并可以帮助减少段数量，从而释放磁盘空间。
Merge 默认是自动进行的，生产环境中避免过度依赖手动的 Merge 操作。
不会改变 index 中的age 时间，不会影响lifecycle 执行
"refresh_interval" : "2m",较长的刷新间隔可以减少 Merge 的频率，从而降低系统开销。
如果是大于5GB的段，不会在执行自动合并策略，从而导致磁盘使用量增加和搜索性能变差。
强制合并期间API阻塞，后台运行不会中断，
ilm 中配置forcemerge，允许的阶段：热、温。操作使索引变为只读。在hot 节点执行影响写入速度

目前集群基本信息

GET _cluster/stats  1013 ms
"indices" : {
    "count" : 6067,
    "shards" : {
      "total" : 35000,
      "primaries" : 17500,
    "docs" : {
      "count" : 144555016341,
      "deleted" : 721947650
    },
    "store" : {
      "size_in_bytes" : 283243198204802,
      "total_data_set_size_in_bytes" : 283243198204802,
      "reserved_in_bytes" : 0
    },
    "mem" : {
        "total_in_bytes" : 26835101253632,
        "free_in_bytes" : 3831963340800,
        "used_in_bytes" : 23003137912832,
        "free_percent" : 14,
        "used_percent" : 86
      }
"segments" : {
      "count" : 609766,
      "memory_in_bytes" : 12125386176,
      "terms_memory_in_bytes" : 10213429672,
      "stored_fields_memory_in_bytes" : 800820848,
      "term_vectors_memory_in_bytes" : 0,
      "norms_memory_in_bytes" : 115028864,
      "points_memory_in_bytes" : 0,
      "doc_values_memory_in_bytes" : 996106792,
      "index_writer_memory_in_bytes" : 13139378392,
      "version_map_memory_in_bytes" : 429915824,
      "fixed_bit_set_memory_in_bytes" : 2942835072,
      "max_unsafe_auto_id_timestamp" : 1706247568250,
      "file_sizes" : { }


Disk Available 61.19% 106.7 TB / 174.3 TB
JVM Heap 44.68% 969.6 GB / 2.1 TB

关于调整前后请求速度优化总览

集群显示情况：因为大部分请求都是基于热数据请求，索引前后对比可能不明显，

关于自动Merge 配置

自动Merge不需要人为参与，forcemerge也尽量不要超过自动Merge的条件，所以保持默认即可

#index settings
"merge" : {
    "scheduler" : {"max_thread_count" : "1"   #线程为1，非ssd保持默认即可
    }},

PUT _ilm/policy/my_policy
{ ···
    "forcemerge" : { "max_num_segments": 1   #最大合并为1，需要结合Rollover 才能生效

forcemerge配置

关于只读索引测试

索引只读一般会涉及到如下三个配置：
"index.blocks.read_only_allow_delete": true,   #只读时允许删除，磁盘使用达到disk.watermark.low是集群会自动配置 ---不影响forcemerge 执行

"index.blocks.read_only": true,                   #索引和索引元数据只读，disk.watermar也会自动配置和删除此配置    ---影响forcemerge 执行
     POST /my-index-000001/_forcemerge
     提示： "reason" : "index [my-index-000001] blocked by: [FORBIDDEN/5/index read-only (api)];"

"index.blocks.write": true                       #lifecycle中可以配置                                           ---不影响forcemerge 执行

一般在forcemerge 中强调只读索引，本身在执行的过程中并不会设置索引只读
不过在lifecycle中配置中，必须使用 rollover ，并且rollover过程中会将index 设置成 read-only

https://www.elastic.co/guide/en/elasticsearch/reference/7.17/ilm-forcemerge.html
Force merge
Phases allowed: hot, warm.
Force merges the index into the specified maximum number of segments. This action makes the index read-only.
To use the forcemerge action in the hot phase, the rollover action must be present. If no rollover action is configured, ILM will reject the policy.

GET my-*/_settings/?filter_path=**.blocks
     "index.blocks.write": "true"

ps：rollover 生成的空索引状态一直为 "step" : "check-rollover-ready"不会forcemerge也不会转移到warm或者cold节点

关于forcemerge 参数

#! 不赞成同时设置only_expunge_delete和max_num_segments，并且在将来的版本中将被拒绝
#POST /my-index-000001/_forcemerge?max_num_segments=1&only_expunge_deletes=true

max_num_segments：要合并到的段数 最大为1
only_expunge_deletes： 默认为false. 这只会合并删除文档比例较高的段，从而减少对性能的影响，index.merge.policy.expunge_deletes_allowed：默认为 10%
flush：强制合并后对索引执行刷新。默认为true.
expand_wildcards：默认是open 状态的索引

关于forcemerge 前后磁盘与内存占用、执行时间在脚本中实现统计

规则视实际情况可以做出对应的调整

notice: index 匹配条件： *-%Y.%m.%d格式  且为10天-17前的，  cold节点的索引
                        必须是 "index.blocks.write": "true"
                        merges.total != 0  # 忽略 减少对性能的影响，后期可以调整
                        index大小(pri.store.size) 大于100G  不处理

            # 根据shards 数量 配置max_num_segments数量，选择不同处理方式
            #     level1: 设置于max_num_segments=1
            #     level2: 保持默认参数
            #     level3: 设置 only_expunge_deletes=true 只会合并删除文档比例较高的段，从而减少对性能的影响
            #     leveln: 动态设置于max_num_segments=n
            #
            #   index大小(pri.store.size) 大于500G    不处理
            #   index大小(pri.store.size) 200G~500G  level3
            #   index大小(pri.store.size) 100G~200G  level2
            #   index大小(pri.store.size) 2G~100G
            #        segments 小于2G 配置成2G
            #   index大小(pri.store.size) 小于2G      level1

        每天 4:30-7:30执行

Force Merge 为什么 pri.store.size 却上升了

"Force Merge" 是指在 Elasticsearch 中对索引执行强制合并（force merge）操作，这个操作将减少索引片段的数量，并且可以提高查询性能和减少磁盘空间占用。
当你执行 force merge 操作后，你可能会观察到 pri.store.size 上升的情况。这是因为 force merge 操作会创建新的合并段（merged segment），这些合并段通常比原始的片段更大。虽然 force merge 操作会减少索引的碎片化程度，但是在合并过程中可能会产生一些临时的额外存储占用。
另外，force merge 操作会产生额外的 I/O 负载，因为它需要读取旧的索引片段并将它们合并成更大的新片段。这可能导致临时的存储空间占用和增加的磁盘写入。
总的来说，虽然 force merge 操作会在某些情况下提高查询性能和减少存储空间占用，但它也可能导致临时的存储空间上升和额外的 I/O 开销。因此，在执行 force merge 操作时，你需要权衡这些因素，并根据具体情况进行评估和监控。