Elasticsearch集群规划及性能优化实践（笔记）

╰半橙微兮° 2022-12-06 04:20 355阅读 0赞

# ES集群容量及索引规划 #

## 1 集群规模评估 ##

*  评估什么
    
     *  计算资源的CPU和内存
     *  存储资源的类型及容量
     *  节点数量
 *  根据什么评估
    
     *  业务场景：日志分析、指标监控、网站搜索
     *  查询及写入QPS
     *  索引数据总量
 *  集群规模评估准则
    
     *  32C64G单节点配置通常可承载5W次/s的写入；
     *  写入量和数据量较大时，优先选择32C64G的节点配置；
     *  1T的数据量预计需消耗2-4GB的内存空间；
     *  实际存储空间通常为原始数据量2.8倍（1副本）
     *  搜索场景优先选择大内存节点配置

## 2 索引配置评估 ##

*  评估什么
    
     *  怎么划分索引
     *  索引的分片数如何设置
 *  根据什么评估
    
     *  业务场景：日志分析、指标监控、网站搜索
     *  单日新增的数据量
 *  索引配置评估准则：
    
     *  单个分片大小控制在30-50GB
     *  集群总分片数量控制在3w以内
     *  1GB的内存空间支持20-30个分片为佳
     *  一个节点建议不超过1000个分片
     *  索引分片数量建议和节点数量保持一致
     *  集群规模较大时建议设置专用主节点
     *  专用主节点配置建议在8C16G以上
     *  如果是时序数据，建议结合ILM索引生命周期管理

# ES集群写入性能优化 #

*  写入性能优化
    
     *  写入数据不指定doc\_id，让 ES 自动生成
     *  使用自定义 routing 功能，尽量将请求转发到较少的分片
     *  对于规模较大的集群，建议提前创建好索引，且使用固定的 Index mapping
     *  对于数据实时性要求不高的场景，可以将索引的 refresh\_interval 设置为 30s
     *  对于追求写入效率的场景，可以将正在写入的索引设置为单副本，写入完成后打开副本
     *  使用 bulk 接口批量写入数据，每次 bulk 数据量大小控制在 10M 左右
     *  尽量选择 SSD 磁盘类型，并且可选择挂载多块云硬盘（云上目前最大支持 3块盘）

# ES集群运维经验总结 #

## 常见分片未分配原因总结： ##

1、磁盘满了：

the node is above the high watermark cluster setting \[cluster.routing.allocation.disk.watermark.high=95%\], using more disk space than the maximum allowed \[95.0%\], actual free: \[4.055101177689788%\]

解决方法：  
扩容磁盘或者删除数据

2、分配文档数超过最大值限制：  
failure IllegalArgumentException\[number of documents in the index cannot exceed 2147483519  
解决方法：  
向新索引中写入数据，并合理设置分片大小

3、主分片所在节点掉线：  
cannot allocate because a previous copy of the primary shard existed but can no longer be found on the nodes in the cluster  
解决方法：  
找到节点掉线原因并重新启动节点加入集群，等待分片恢复  
4、索引属性与节点属性不匹配：  
node does not match index setting \[index.routing.allocation.require\] filters \[temperature:“warm”,\_id:“comdNq4ZSd2Y6ycB9Oubsg”\]

解决方法：  
重新设置索引的属性，和节点保持一致，若要修改节点属性，则需要重启节点

5、节点长时间掉线后再次加入集群，导致引入脏数据  
cannot allocate because all found copies of the shard are either stale or corrupt

解决方法：  
使用reroute API：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4_size_16_color_FFFFFF_t_70_pic_center]  
6、未分配的分片太多，导致达到了分片恢复的最大阈值，其他分片需要排队等待  
reached the limit of incoming shard recoveries \[2\], cluster setting \[cluster.routing.allocation.node\_concurrent\_incoming\_recoveries=2\] (can also be set via \[cluster.routing.allocation.node\_concurrent\_recoveries\])

解决方法：  
使用cluster/settings调大分片恢复的并发度和速度：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4_size_16_color_FFFFFF_t_70_pic_center 1]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4_size_16_color_FFFFFF_t_70_pic_center 2]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/ed868976b6894419ab93126a66953f2b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/bc1c132805d049d5b5926e787cbcab5b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/58bb1253106942959242fc7d4b0abe84.png