Elasticsearch 集群节点cpu 使用率过高

Posted 2023-04-28

参考技术A 话不多说，笔者所在公司ES生产集群 20+，机器 400+，经常会有cpu持续很高情景，一般使用率超过 90 会收到告警~~~

两种方案

1、使用 hot_threads api

2、使用 top + jstatck 获取堆栈信息

具体参考

线上排查 CPU 100% (适用于 线上的一些 java 应用)

Elasticsearch深入Elasticsearch集群

7.1 节点发现
启动Elasticsearch的时候，该节点会寻找有相同集群名字且课件的主节点，如果有加入，没有自己成为主节点，负责发现的模块两个目的
选出主节点以及发现集群的新节点
7.1.1发现的类型
Elasticsearch允许使用zen发现，在config里面的Elasticsearch.yml里面配置zen的信息即可，使用2.1.0的时候是这样的
7.1.2主节点
发现的功能之一就是选主节点，应该是zookeeper完成的，并且保持之间有相应
配置主节点和数据节点：Elasticsearch允许节点同时成为主节点和数据节点，但是可以根据自己的要求去设置，比如只做主节点，不做数
据节点等
主节点选取的配置：脑裂是比如一个集群十个节点，有三个断开，然后三个成为一个集群，所以一共有两个集群，成为脑裂，为了避免这种
情况，需要设置zen.minimum_master_nodes即可，设置为总个数+1的50%才可以成为集群，即可防止这种情况发生
7.1.3 设置集群名
设置Elasticsearch.yml文件里面cluster.name的值
配置多播：多播是zen发现的默认方法，除了常见设置，还可以控制群组地址，多播通信端口号，多拨请求被认为有效的时间，以及
Elasticsearch应该绑定的地址
配置单播：即需要配置ip以及端口号，以便被集群发现
7.1.4 节点的ping设置
可以控制或者改变默认的ping设置，ping是节点间发送的信号用来检测是否运行，可设置时间间隔，重复次数，以及默认等待时间等

7.2 时光之门与回复模块
一些重要信息例如索引、索引数据等信息需要被持久化到别的地方，里边在发生意外的时候恢复时读取，这就时时光之门的作用
7.2.1 时光之门
时光之门的类型可以在elasticsearch.yml里面添加gateway.type属性，设置为local，默认的类型是在本地文件系统中存储索引
7.2.2 恢复控制
可以设置什么时候启动恢复的过程，例如总共十个节点，在八个节点之后恢复，或者在八分钟之后恢复这样的设置
额外的gateway恢复选项
recover_after_master_nodes：指定多少有资格成为主节点的节点在集群中出现时才开始恢复
recover_after_data_nodes：指定多少个数据节点在急群众出现时才开始启动恢复
7.3 为高查询和高索引吞吐量准备Elasticsearch集群
如何调优使集群可以应对高查询以及高索引吞吐量
7.3.1 过滤器缓存
过滤器缓存可以提高查询速度，尤其是那些包含已经执行过的过滤器的查询，包含两类，一类是节点过滤器缓存，为默认的，另外一种为索
引过滤器缓存，第一种缓存可设置成使用特定大小的内存或者分配给Elasticsearch总内存的百分比
7.3.2 字段数据缓存和断路器
字段数据缓存：当查询对字段执行排序或者切面时，Elasticsearch把该字段的数据加载到内存，以便快速访问，可以设置
indices.fileddata.cache.size属性控制，可以设置为绝对值或者百分比，均为节点级别，也可以使用indices.filddata.cache.expire来
控制设置最大的不活动时间，但是一般情况下不设置，因为重建字段数据缓存是非常昂贵的
断路器：允许估计一个字段加载到缓存所需要的内存，通过抛出异常防止字段加载内存，造成内存爆炸，有两个属性，第一个是
indicies.filddata.breaker.limit属性，默认为80%，第二个是indices.fielddata.breaker.overhead默认为1.03
7.3.3 存储模块
存储模块控制如何写入索引数据，可以存储在内存或者一个持久化的磁盘中，内存快但是不稳定，索引慢，但是容忍故障
使用index.store.type来制定哪种存储类型
simplesf：基于磁盘的存储，对并发访问的性能不够好
niofs：使用javanio类访问索引文件，高并发性能好，但是不能再windows下
mmapfs：基于磁盘的存储，在内存中映射索引文件，为64为系统下的默认存储，读操作更快，但是要有足够数量的虚拟地址空间
memory：将索引存在内存中，必须内存够大，否则会失败
7.3.4 索引缓冲和刷新率
Elasticsearch允许设置索引最大的内存数，例如设置百分比等，还有indices.memory.min_shard_index_buffer_size默认为4mb，为每个分
片设置最小索引缓冲
索引刷新率：index.refresh_interval属性，指定多久刷新一次，默认为1s，值越小表示时间越短，也意味着索引和搜索会变慢，在重建索
引截断，建议将其设置为-1
7.3.5线程池得配置
Elasticsearch公开的线程池类型有，cache无限制的线程池，fixed固定大小的线程池，大小由size设置
重要的线程池有下面几个：
index：用来索引和删除操作，默认为fiexed，默认可用处理器的数量为300
search：用于搜索和计数请求，默认为fixed，size为可用处理器的数量乘以3，队列的size默认为1000
suggest：用于建议器的请求，默认为fixed，size为可用处理器的的数量，队列的size默认为1000
get：用于实时get请求，fixed，队列默认size为50
bulk：用于批量操作，fixed，size默认为可用处理器的数量（这句话应该如何理解），队列的size默认为50
线程池得配置可以在yml文件设置，也可以使用集群的更新api来更新，此处给出例子了
7.3.6 结合起来，一些通用建议
选择正确的存储：在64位时选用mmapfs，如果没64位，为unix系统选择niofs，为windows选择simplefs
索引刷新率：刷新率越快，查询越慢，索引吞吐量越低
优化线程池：强烈建议调整默认线程池，尤其是查询操作
优化合并过程：查询快需要更少的段，索引快需要更多的段，在什么时候合并需要自己根据情况取舍
字段数据缓存和断路器：限制字段数据缓存大小，设置断路器，两者结合确保不会遇到内存问题
索引的内存缓冲区：内存缓冲区的内存越多，越多的文档可以在里面保存，可以设置10%-30%
优化事务日志：Elasticsearch内部的translog模块，默认情况保存最多5000次操作，最大不超过200mb，如果想提高索引吞吐量，又可以承
担数据对搜索操作不可见的时间更长，可以提高这个默认值，如果提高可能做完索引到搜索课件需要更长的时间
7.4 模板和动态模板
索引模板的功能，不需要每次都创建映射等
模板的一个例子：给出模板的例子
在文件中存储模板：可以在config/templates目录中存放模板
7.4.2 动态模板
给出一个动态模板的例子，两种匹配模式，match模式使用该模板，unmatch模式使用该模板

更多请点：http://blog.csdn.net/molong1208?viewmode=contents