这是一个创建于 1630 天前的主题，其中的信息可能已经有所发展或是发生改变。
0. 背景
a. 刚入职几天，主要负责维护公司的 ES 集群，头大。。。
b. 简单整理了集群的相关情况，见下文，烦请有相关经验的大佬，帮忙看看优化方法合理吗，有没有更好的建议，非常感谢。
c. 自己感觉集群资源已经非常充足了，但不合理的节点配置和不完善的索引管理策略 [严重] 影响了整体的性能
d. 自己对 ES 维护优化经验不多，欢迎大佬指点一二。
1. 集群概况
a. 版本信息：CentOS7, ES 7.3.0, 单机多实例配置
b. 数据方面：20+ indices，650+ shards，80 亿+ doc
c. 节点方面：1 master，36 data + ingest + coordinating , 1 ingest + coordinating
e. 资源方面：具体如下图，每个数据节点挂载了两块 1.5T 的机械磁盘，并都配在了 path.data 下。
2. 索引情况
a. 每个索引 32 个分片，1 个副本分片
b. 每月生成一个新索引，按月滚动
c. 单个索引有 500G ~ 800G 数据量
d. 索引中使用了 [父子文档]
e. 单个分片中有些超过了 26G
f. 从 2019.11 ~ 2020.5 数据增长来看，每天大概增长 20G 左右
3.索引管理
a. 没有划分节点属性，也就没有做冷热数据分离
b. 索引生命周期管理不完善，仅仅对超过 30 天的索引 forcemerge 和超过 90 天的副本分片置为 0，freeze 索引
4.当前问题
a. 数据节点有时会离线 （猜测是不合理的查询耗尽了堆空间）
b. 写入数据慢，rabbitmq 队列数据堆积 （还没整明白具体的情况）
c. 集群恢复耗时长 (应该是索引没有划分优先级)
d. 下图是 kibana 24h 的数据，索引包含了 kibana 的一些索引和分片，上述叙述中去掉了该部分。
5.优化思路
a. 根据主机资源情况划分合理的节点角色，节点属性，提高集群的资源利用性，可用性，健壮性。
b. 冷热数据分离，hot 节点高配置低存储，warm 节点低配置大存储。
c. 热数据节点单主机单实例，冷数据节点单主机多实例。
d. 索引生命周期的管理，包括减少主分片数，合适的模板，索引 Rollover，索引 Allocation 等。
e. 健全 ES 主机资源监控告警，JVM 重点指标监控告警。
 |
1
liamyoung 2020-05-30 22:20:32 +08:00
看看哪种 gc 方法更适用、禁止使用 swap 空间、es 的版本升级高一点(低版本的 es 消耗内存更多)
|
 |
2
hasdream 2020-05-30 22:25:47 +08:00
es 集群 热数据 SSD 冷数据 机械硬盘
写入慢 每台几个 多个 data.path 每个对应一组 RAID 盘 观察系统的 IOWAIT 信息 (分片 尽量平衡每台机器) 监控 推荐 promethus (node_exporter elasticsearch_exporter ) 观察主机写入 IOPS 和 IOWAIT 及 ES 集群 GC 等 |
 |
3
rrfeng 2020-05-30 22:44:40 +08:00 via Android
上面方案已经不错了，再提一点就是 index mapping 是否合理设置非常影响性能。
关闭过期索引，冷热分离，索引预建，控制分片大小。写入的话提高刷新间隔，写入时单副本，写完再增加 replica （如果数据安全要求没那么高的话） |
 |
6
SKYNE OP @rrfeng 索引 mapping 合理性确实需要多花时间研究下，据同事说对数据实时性要求不高，refresh_interval 已经调到 30s 了。非常感谢您的建议。
|
 |
7
hackerwin7 2020-05-31 09:08:18 +08:00 via iPhone
需要明确下 data 节点离线的原因。如果是脏查询的话，集群优化的效果恐怕并不明显
|
|
8
SKYNE OP @hackerwin7 请问，脏查询具体指的是什么呢
|
Select Language