20220328es

Mar 28, 2022

es

es 使用curl

$ alias curles='curl  -u elastic:elasticpassword'
$ curles -XPUT "http://localhost:9200/movies/movie/1" -d''
$ curles -X POST "http://172.16.60.162:9200/_analyze" -d '{"analyzer":"standard", "text":"Like X 国庆放假的"}' -H "Content-Type: application/json"

为es 增加stopword 和词汇

增加stopword 和词汇的操作

$ docker cp ${dockerId}:/usr/share/elasticsearch/plugins/ik/config config
// 支持往custom/mydic.dic 写入对应合并关键词、custom/ext_stopword.dic
$ mkdir config/custom && touch config/custom/mydict.dic && touch config/custom/ext_stopword.dic
$ docker cp config ${dockerId}:/usr/share/elasticsearch/plugins/ik // 拷贝配置文件回elastic
$ docker restart ${dockerId} // 重启elastic

↑支持的plugins语法

语法如:

1
2
3
新案件
不要
不可

[search.max_open_scroll_context]

PUT 更新下配置即可:

1
2
3
4
5
6
7
8
9
curl -XPUT --user elastic:123456 "http://localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d '
{
  "persistent": {
    "search.max_open_scroll_context": 1024
  },
  "transient": {
    "search.max_open_scroll_context": 1024
  }
}'

FORBIDDEN/12

该表示为磁盘空间已不足90%，可以配置使用磁盘空间比例，但是推荐扩容磁盘大小，90%已经是比较危险的使用大小了。

扩容磁盘大小后，将所有索引再重置下，否则只能读，不能创建或者更新等操作:

1
2
3
4
curl -XPUT --user elastic:123456 "http://localhost:9200/_all/_settings" -H 'Content-Type: application/json' -d '
{
  "index.block.read_only_allow_delete": null
}'

Data too large

Data too large 表明了ES内存已达到当前数据存储上线。

解决方案目前是两个:

  1. 扩容机器数据内存；
  2. 设置熔断驱逐数据；

这里记录2中设置熔断驱逐数据:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
docker-compose.yml
services:
  elasticsearch:
    volumes:
      - ./elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml

elasticsearch.yml
cluster.name: "docker-cluster"
network.host: 0.0.0.0
indices.breaker.total.use_real_memory: false
indices.breaker.total.limit: 60%
indices.fielddata.cache.size: 45%
indices.requests.cache.size: 20%
indices.breaker.fielddata.limit: 35%
indices.breaker.request.limit: 50%
network.breaker.inflight_requests.limit: 50%
indices.breaker.accounting.limit: 50%

参考文档1

参考文档2

Data too large解决记录

Data too large / 429 Too Many Requests 这个问题由来已久。之前考虑是关闭某些年份数据，但是仍然会报那个问题。

思考就是数据加载到内存后，如果继续增加，而没有把旧数据驱逐，则肯定会超过内存数据大小，于是对应上述方案: 增加内存，让他不到达最大内存(好处是都加载到内存，快)；驱逐旧数据，加载新数据。

查看数据: GET /_stats/fielddata?fields=*

fielddata中的memory_size_in_bytes表示已使用的内存总数，而evictions(驱逐数据)为0.且经过一段时间观察，字段所占内存大小都没有变化。由此推断，当下缓存处于无法有效驱逐的状态。

最重要的是设置好fielddata cache大小和熔断点大小indices.fielddata.cache.size 和indices.breaker.fielddata.limit

参考文档总结中挺有帮助的:

  • 系统默认的indices.fielddata.cache.size 是不限制大小的，本意是想通过报错告知维护者需要做配置，是否搜素的数据有误。
  • fielddata.limit 的配置需要比fielddata.cache.size稍大。而fielddata缓存到达fielddata.cache.size的时候就会启动自动清理机制。expire配置不建议使用。
  • indices.breaker.request.limit限制查询的其他部分需要用的内存大小。indices.breaker.total.limit限制总(fieldData+其他部分)大小。
  • 创建mapping时，可以设置fielddata format控制缓存数据格式。

ES需要高速内存读取，首要达到硬件内存通过集群扩容大于数据大小。此时体现在数据快速读取，大量人员内存操作的场景。如果是人员人数不多，非必要大量数据高速存取场景，则可通过ES熔断机制驱逐旧数据，达到存取平衡。

故，非超大型查询场景是可以不采用集群方案(超大型集群调节熔断配置)，单节点可以满足配置中熔断数据(根据ES_JAVA_OPTS 比例值)。

此处描述配置作用:

1
2
3
4
5
6
7
8
9
10
11
cluster.name                            集群名称
network.host                            网络配置
network.breaker.inflight_requests.limit 请求中熔断器
indices.fielddata.cache.size            类型为text进行sort/aggs时加载fielddata到内存
indices.requests.cache.size             shard request cache热点请求cache
indices.memory.index_buffer_size        索引操作大小(default:10%)
indices.breaker.total.use_real_memory   可以更加精准的分析内存状况，避免 OOM
indices.breaker.total.limit             配置总内存大小
indices.breaker.fielddata.limit         field 内存数据加载大小
indices.breaker.request.limit           防止单个请求内存溢出
indices.breaker.accounting.limit        已请求完的请求所占用内存占比

查看是否配置成功及查询现有配置:

alias escurl='curl --user ${esuser}:${espass}'
escurl -XGET "http://${eshost}:9200/_nodes/_all/settings?pretty"

参考说明 https://blog.csdn.net/u013200380/article/details/109285118