ElasticSearch 运维

最新推荐文章于 2024-05-31 11:37:58 发布

QQsilhonette

最新推荐文章于 2024-05-31 11:37:58 发布

阅读量564

点赞数

文章标签： elasticsearch

本文链接：https://blog.csdn.net/QQsilhonette/article/details/107620969

版权

1、es生产集群部署规划建议

1）内存

es吃的主要不是jvm heap（堆内存），主要吃的是机器内存。

es底层基于lucene，lucene特点是基于os filesystem cache，会尽量将频繁访问的磁盘文件的数据在操作系统的内存中进行缓存来提升读写性能。因此当大量索引文件在os cache中放不下，停留在磁盘上，会导致搜索性能很低，跟os cache相差一个数量级ms,s。

几万、几十万、几百万数据量对于及其资源配置要求低。但是到达过亿、几十亿就比较大了。

建议每台机器64G内存，最小不能低于8G。

2）CPU

cpu core数量多，性能一般 > cpu core性能好，数量少，有更强的并发处理能力。

3）磁盘

对于es的生产环境，磁盘非常重要，因为磁盘是最慢的资源，很容易因为磁盘的读写性能造成整个集群的瓶颈。

SSD > 机械硬盘（配置正确的IO scheduler）

4）网络

集群避免跨多个数据中心

5）自建集群 vs 云部署

尽量用少量的大资源虚拟机，也要尽量避免那种超大资源量的超级服务器，因为那样可能造成资源无法完全利用，然后在一个物理机上部署多个es节点，这会导致我们的集群管理更加的复杂。

6）JVM

不要随便调节jvm参数

7）容量规划

中小型公司，建议es集群承载的数据量在10亿规模以内。

估算：

比如10亿条数据100G

5台64G，8核，300G，一半150G分给jvm heap，物理内存剩余150G，还有50G的其他损耗，最后剩余100G

es会加入自己的信息膨胀一倍到200G

因此，50%会基于磁盘进行索引读写，请求有可能达到几秒。

2、集群发现机制

1）默认情况下，es进程会绑定在自己的回环地址上，也就是127.0.0.1，然后扫描本机上的9300~9305端口号，尝试跟那些端口上启动的其他es进程进行通信，然后组成一个集群。生产环境下，要使用非回环地址。

2）es是一种peer to peer，不是hadoop生态普遍采用的那种master-slave主从架构的分布式系统。集群中的每个node是直接跟其他节点进行通信的，几乎所有操作都是client跟任何一个node进行通信，那个node再将请求转发给对应的node来进行执行。

3）正常情况下master node只有一个，负责维护整个集群的状态信息，每次cluster state发生变化，master会负责将集群状态同步给所有的node，集群中的所有node都会有一份完整的cluster state。

4）多个node必须要设置一个cluster.name才能组成一个集群。

5）es默认配置为使用unicast集群发现机制，即提供一个es种子node作为中转路由节点就可以了，利用ping来发现。如果是采用multicast，遇到轻微的网络抖动，可能会导致节点无法发现对方。

6）生产环境下可以给集群规划处专门的master eligible node，es会从中选举一个作为master node，其余的还是作为data node使用，但是在master node发生故障时可以接替。小于10个节点，所有节点都可以同时作为master eligible node和data node。

7）集群故障探查：第一种是通过master进行的，master会ping集群中的所有其他node；第二种是每个node都会去ping master node确保master node存活，否则会发起一个选举，集群至少有3个节点保证master宕机后可以成功选举。

8）集群状态更新时，master node会将更新后的发布状态发送到集群中的所有node上去；如果在指定时间内，指定数量的node ack这个message，那么这个cluster state就会被commit，然后会再次发送message给每个node；node接收到commit message后会将集群状态应用到自己的副本并响应更新副本成功，master node等待所有节点响应后会继续处理下一个更新状态。

9）master宕机阻塞操作：write，默认是拒绝全部写操作，但是允许读操作；all，所有操作都拒绝。

3、集群参数设置

1）es大多数默认参数基本不需要修改；

2）生产环境下集群名称必须要设置，避免某个机器无意加入了集群；node节点名称不指定，重启后会变化，因此也需要手动指定。

3）默认情况下，es会将各个目录放在安装目录中，这样es升级时会将这些目录覆盖，最好将log、plugins、data放在安装目录之外。

一般建议的目录地址是：

mkdir -p /var/log/elasticsearch
mkdir -p /var/data/elasticsearch
mkdir -p /var/plugin/elasticsearch
mkdir -p /etc/elasticsearch

path.logs: /var/log/elasticsearch
path.data: /var/data/elasticsearch
path.plugins: /var/plugin/elasticsearch

config：/etc/elasticsearch

4）es默认将某个shard都分配到一个磁盘上，不会将shard的数据条带化存储到多个磁盘上。生产环境下很少使用es的multiple data path策略，最好还是采用专门的RAID软件来进行机器磁盘存储。

4、集群恢复参数配置

gateway.recover_after_nodes: 8 // 至少有8个节点上线才开始恢复

gateway.expected_nodes: 10 // 集群中至少有10个节点

gateway.recover_after_time: 5m // 等待最多5分钟

es集群的行为：等待至少8个节点在线，然后等待最多5分钟，或者10个节点都在线，开始shard recovery的过程。

这样避免少数node启动时，就立即开始shard recovery，进而避免大量无意义的复制、移动和删除。

5、es threadpool

一般threadpool配置为：cpu core核数 * 3 / 2 + 1，设置过多的线程数会导致线程上下文的切换，一个core同一时间只能执行一个线程，如果切换发生在不同的core之间会消耗更多cpu资源，每次线程切换会消耗约30微秒的时间开销。

不需要担心磁盘IO被block住，threadpool还会通过在彼此之间传递任务来协作执行，我们不需要担心某一个网络线程会因为等待一次磁盘写操作，而导致自己被block住，无法处理网络请求。网络线程可以将那个磁盘写操作交给其他线程池去执行，然后自己接着回来处理网络请求。

6、jvm heap和服务器内存分配

1）es默认会给jvm heap分配2G，对于生产环境来说太小了。jvm.options文件里面去设置，最大内存-Xms和最小内存-Xmx设置成一样，避免运行过程中resize。

2）一般建议将50%的内存分配给es jvm heap，留50%的内存给os cache，因为lucene的性能严重依赖于底层os的，os cache会将hot segment驻留在内存中，segment包含了倒排索引和正排索引。

3）不要给jvm分配超过32G内存（设置31G比较安全），由于小于32G时，jvm会使用compressed oops（https://blog.csdn.net/liuxiao723846/article/details/91981757）来解决object poointer耗费过大空间的问题，当超过了32G时，jvm又会回退到传统的object pointer引用对象的二进制地址的模式，此时object pointer的大小会急剧增长，浪费更多的内存，降低cpu性能。es 要处理上亿、几十亿的数据，建议用64G内存的机器 * 5差不多。

4）关闭swap，es的swap是服务器性能杀手，内存被swap到磁盘，100微秒的操作会变成10毫秒。

7、es生产环境重要系统设置

1）禁止swapping
2）确保拥有足够的虚拟内存
3）确保拥有足够的线程数量

8、索引管理

1）创建索引

url -XPUT 'http://elasticsearch02:9200/twitter?pretty' -d '
{
"settings" : {
"index" : {
"number_of_shards" : 3,
"number_of_replicas" : 2
}
},
"mappings" : {
"properties" : {
"field1" : { "type" : "text" }
}
}
}'

返回值
{
"acknowledged": true, // 标明索引创建成功，有可能因超时而失败，但是创建成功
"shards_acknowledged": true // 是否有足够数量的replica进行复制
}

2）删除索引

curl -XDELETE 'http://elasticsearch02:9200/twitter?pretty'

删除索引中的一个type

3）查询索引设置信息

curl -XGET 'http://elasticsearch02:9200/twitter?pretty'

4）打开/关闭索引

curl -XPOST 'http://elasticsearch02:9200/twitter/_close?pretty'
curl -XPOST 'http://elasticsearch02:9200/twitter/_open?pretty'

5）压缩索引

1）首先，以相同配置创建目标索引，但是主分片数量减少。
2）然后硬链接（ hard-linking ）各部分自原索引到目标索引。（如果系统不支持硬链接，那么索引的所有部分都将复制迁移到新索引，将会花费大量时间）
3）最终，将会恢复目标索引，因为目标索引刚被重新打开就会被关闭。

curl -XPUT 'http://elasticsearch02:9200/twitter/_settings?pretty' -d '
{
"settings": {
"index.routing.allocation.require._name": "node-elasticsearch-02",
"index.blocks.write": true
}
}'

curl -XPOST 'http://elasticsearch02:9200/twitter/_shrink/twitter_shrinked?pretty' -d '
{
"settings": {
"index.number_of_replicas": 1,
"index.number_of_shards": 1,
"index.codec": "best_compression"
}
}'

当然也是需要监控整个shrink的过程的，用GET _cat/recovery?v即可。

6）rollover index

这个过程常见于网站用户行为日志数据，比如按天来自动切分索引，写个脚本定时去执行rollover，就会自动不断创建新的索引，但是别名永远是一个，对于外部的使用者来说，用的都是最新数据的索引。

curl -XPUT 'http://elasticsearch02:9200/logs-000001?pretty' -d '
{
"aliases": {
"logs_write": {}
}
}'

curl -XPOST 'http://elasticsearch02:9200/logs_write/_rollover?pretty' -d '
{
"conditions": {
"max_age": "1d",
"max_docs": 3
}
}'

6）translog

每个shard都有一个transaction log，也就是translog，来写入write ahead log，预写日志。任何写入数据都会同时被写入translog。如果机器挂掉了，那么就可以重放translog中的日志来恢复shard中的数据。

一次es flush操作，都会执行一次lucene commit，将数据fsync到磁盘上去，同时清空translog文件。在后台会自动进行这个操作，来确保translog日志不会增长的太过于巨大，这样的话重放translog数据来恢复，才不会太慢。

9、es基本性能优化

1）搜索结果不要过大，如果真的要做大批量结果的查询要使用scroll api；

2）避免超大的document（默认100mb）

3）避免稀疏的数据，因为如果一个索引有100个document，对于每个field，就需要100个字节来存储norm值（norm就是每个document的每个field保留的一个字节），即使100个document中只有10个document含有某个field，但是对那个field来说，还是要100个字节来存储norm值。这就会对存储产生更大的开销，存储空间被浪费的一个问题，而且也会影响读写性能。

解决办法：

避免将没有任何关联性的数据写入同一个索引

对document的结构进行规范化/标准化

对稀疏的field禁用norms和doc_values

10、es写入性能优化

5,6,7,8,9比较通用

1）用bulk批量写入

2）使用多线程

3）增加refresh间隔

4）禁止refresh和replica（针对一次性加载大批量数据）

5）禁止swapping交换内存（内存与磁盘交换数据性能差）

6）给filesystem cache更多的内存