本篇不详写prometheus、grafana的搭建,需要可以翻阅linux监控篇
ElasticSearch入门篇
一、监控
- docker-compose.yml
elasticsearch_exporter: #监控
image: quay.io/prometheuscommunity/elasticsearch-exporter:v1.3.0
command:
- '--es.uri=http://elasticsearch:9200'
- '--es.all'
- '--es.indices'
- '--es.indices_settings'
- '--es.indices_mappings'
- '--es.shards'
- '--es.snapshots'
- '--es.timeout=30s'
restart: always
ports:
- "9114:9114
参数说明
–es.uri
默认http://localhost:9200,连接到的Elasticsearch节点的地址(主机和端口), 这可以是本地节
点(例如localhost:9200),也可以是远程Elasticsearch服务器的地址
–es.all
默认flase,如果为true,则查询集群中所有节点的统计信息,而不仅仅是查询我们连接到的节点。
–es.cluster_settings
默认flase,如果为true,请在统计信息中查询集群设置
–es.indices
默认flase,如果为true,则查询统计信息以获取集群中的所有索引。
–es.indices_settings
默认flase,如果为true,则查询集群中所有索引的设置统计信息。
–es.shards
默认flase,如果为true,则查询集群中所有索引的统计信息,包括分片级统计信息(意味着es.indices
= true)。
–es.snapshots
默认flase,如果为true,则查询集群快照的统计信息。
docker compose up -d
- prometheus.yml
- job_name: 'es-export'
static_configs:
- targets: ['xxxxxxx:9114']
- http://ip:9114/metrics
- grafana :模版id:6483
二、优化
2.1 优化策略
在搜索引擎的业务场景下,用户一般并不需要那么高的写入实时性。比如你在网站发布一条征婚信息,或者二手交易平台发布一个商品信息。其他人并不是马上能搜索到的,这其实也是正常的处理逻辑。这个延时的过程需要处理很多事情,业务层面比如:你的信息需要后台审核。你发布的内容在搜索服务中需要建立索引,而且你的数据可能并不会马上被写入索引,而是等待要写入的数据达到一定数量之后,批量写入。这种操作优点类似于我们快递物流的场景,只有当快递数量达到一定量级的时候,比如能装满整个车的时候,快递车才会发车。因为反正是要跑一趟,装的越多,平均成本越低。这和我们数据写入到磁盘的过程是非常相似的,我们可以把一条文档数据看做是一个快递,而快递车每次发车就是向磁盘写入数据的一个过程。这个过程不宜太多,太多只会降低性能,就是体现在运输成本上面。而对于我们数据写入而言就是体现在我们硬件性能损耗上面。
ES 数据写入具有一定的延时性,这是为了减少频繁的索引文件产生。默认情况下 ES 每秒生成一个segment 文件,当达到一定阈值的时候 会执行merge(合并),merge 过程发生在 JVM中,频繁的生成segment 文件可能会导致频繁的触发 FGC,导致 OOM。为了避免这种情况,通常采取的手段是降低segment 文件的生成频率,手段有两个,一个是 增加时间阈值,另一个是增大 Buffer的空间阈值,因为缓冲区写满也会生成 Segment 文件。
2.2 优化手段
1、增加refresh_interval的参数值
- 默认情况下,Elasticsearch 每秒定期刷新索引, es支持近实时原因
- 如果没有搜索流量或搜索流量很少(例如每 5 分钟不到一个搜索请求)并且想要优化索引写入效率,时间建议加大
PUT /{index}/_settings
{
"refresh_interval": "30s"
}
2、增加Buffer大小
- 本质也是减小refresh的时间间隔,因为导致segment文件创建的原因不仅有时间阈值,还有buffer空间大小,写满了也会创建。
最小值 48MB< 默认值 JVM 空间的10% < 默认最大无限制
indices.memory.index_buffer_size
- elasticsearch.ym配置项indices.memory.index_buffer_size是es写入buffer缓存,默认是jvm heap的10%,设置的这个index buffer大小,是所有的shard公用的,也就是shard越多,每个shard分配的memory就会越少,一般建议,但是对于每个shard来说,最多给512mb,因为再大性能就没什么提升了(主要是segment的大小)
3、关闭Disable swapping
https://blog.csdn.net/wang7075202/article/details/111031589
4、内存问题
在 elasticsearch\config 目录下,有三个核心的配置文件:
- elasticsearch.yml,es相关的配置
- jvm.options,Java jvm相关参数的配置
内存设置
5、熔断保护机制
elasticsearch.yml
# 避免发生OOM,发生OOM对集群影响很大的
indices.breaker.total.limit: 80%
# 有了这个设置,最久未使用(LRU)的 fielddata 会被回收为新数据腾出空间
indices.fielddata.cache.size: 10%
# fielddata 断路器默认设置堆的 作为 fielddata 大小的上限。
indices.breaker.fielddata.limit: 60%
# request 断路器估算需要完成其他请求部分的结构大小,例如创建一个聚合桶,默认限制是堆内存
indices.breaker.request.limit: 60%
6、重启或者手工清理
POST {idnex}/_cache/clear
7、按照年月日建索引
三、jmeter-ES
Content-Type:application/json
1. 插入数据
文章来源:https://www.toymoban.com/news/detail-854062.html
2. 查询数据
文章来源地址https://www.toymoban.com/news/detail-854062.html
到了这里,关于ElasticSearch的监控与优化的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!