Elasticsearch:CPU使用率间歇性陡增解决方案_elasticsearch集群cpu ...

问题排查」：

阿里云方抓取到在CPU使用率监控指标飙高时，有merge线程占用了比较高的CPU，排查点有二：

是否存在定时merge的任务
配置的索引生命周期中是否存在定期的merge操作

解决方案」：

1.获得到某个索引的Edit setting如下：

{

"index.blocks.read_only_allow_delete" : "false" ,

"index.query.default_field" : [

"*"

],

"index.write.wait_for_active_shards" : "1" ,

"index.refresh_interval" : "1s" ,

"index.indexing.slowlog.level" : "info" ,

"index.indexing.slowlog.threshold.index.warn" : "200ms" ,

"index.indexing.slowlog.threshold.index.trace" : "20ms" ,

"index.indexing.slowlog.threshold.index.debug" : "50ms" ,

"index.indexing.slowlog.threshold.index.info" : "100ms" ,

"index.indexing.slowlog.source" : "1000" ,

"index.translog.durability" : "async" ,

"index.unassigned.node_left.delayed_timeout" : "5m" ,

"index.priority" : "1" ,

"index.number_of_replicas" : "0" ,

"index.lifecycle.name" : "aliyun_default_ilm_policy" ,

"index.apack.cube.following_index" : "false" ,

"index.routing.allocation.include._tier_preference" : "data_cold,data_warm,data_hot" ,

"index.search.slowlog.level" : "info" ,

"index.search.slowlog.threshold.fetch.warn" : "500ms" ,

"index.search.slowlog.threshold.fetch.trace" : "50ms" ,

"index.search.slowlog.threshold.fetch.debug" : "100ms" ,

"index.search.slowlog.threshold.fetch.info" : "200ms" ,

"index.search.slowlog.threshold.query.warn" : "1s" ,

"index.search.slowlog.threshold.query.trace" : "100ms" ,

"index.search.slowlog.threshold.query.debug" : "200ms" ,

"index.search.slowlog.threshold.query.info" : "500ms" ,

"index.merge.policy.segments_per_tier" : "30" ,

"index.merge.policy.max_merged_segment" : "512mb"

}

2.通过setting来看，是有merge相关设置的，另外，可以通过GET /_nodes/stats命令，搜索结果中的merges，有这个线程运行的次数，可以在节点CPU打高的前后，看下merges线程运行的次数，主要是看数据节点，目前来看merges的次数挺高的，如果不希望CPU这么频繁的打高，可以对以下两个参数进行调整，降低CPU使用率：

1."index.merge.policy.segments_per_tier" : "30" : 每个tier允许的segement 数，注意这个数要大于上面的at_once数，否则这个值会先于最大可操作数到达，就会立刻做merge，这样会造成频繁

2."index.merge.policy.max_merged_segment" : "512mb" : 超过多大size的segment不会再做merge，默认是5g.

「方案使用成果」：

将"index.merge.policy.segments_per_tier"设置为45，观察CPU使用率监控如图，可以观察到CPU使用率有明显的下降趋势。

将"index.merge.policy.max_merged_segment"设置为256mb后，观察CPU使用率监控如图，可以观察到CPU使用率有明显的下降趋势。

分区表 有很多好处，以大化小，一小化了，加上并行的使用，在loap中能往往能提高几十倍甚至几百倍的效果。当然表设计得不好也会适得其反，效果比普通表跟糟糕。为了更好的使用 分区表 ，这里看一下 分区表 的 执行计划 。 PARTITION RANGE ALL：扫描所有分区 PARTITION RANGE ITERATOR：扫描多个分区，小于所有个分区数量 PARTITION RANGE SINGLE：扫描单一的

创建 分区表 create table part_tab (id int,col2 int,col3 int) tablespace users partition by range (id) partition p1 values less than (10000), partition p2 values less than (20000), partition p3 values less t...

执行计划 中的关键字 partition list single --扫描单个分区 partition list iterator --连续扫描N个分区 partition list inlist --不连续扫描N个分区 partition list full --扫描全部分区？测试结果SQL> drop table test purge; SQL> re...

partition range single:访问单个分区 partition range iterator:访问多个分区 partition range inlist: 分区键中用了in 例如： where n1 in(X1,X2) and n2=X3 partition range all: 所有的分区

建议如下：检查数据库的cpu 消耗，Sql_id :***** 消耗过多资源，这个新上线sql, 20号才上线，是对log 进行分析,平均每次执行时间300s.,使用的是 PARTITION RANGE ALL 相当于全表扫描，该表的数据量达到千万级。建议如下： log 这个表建议做定时数据清理， --------------------------------------...