共计 1653 个字符，预计需要花费 5 分钟才能阅读完成。
集群调优
- elasticsearch.yml 中尽量只写必备参数其余通过 api 动静设置
- 参见文档 setup elasticsearch -》impotant elasticsearch configuration
- 随着 es 降级 很多网络流传的配置参数不再反对
根本参数设置
- cluster.name
- node.name
- node.master/node.data/node.ingest
- network.host 倡议指定的内网 ip 而不是偷懒设置为 0.0.0.0
- discovery.zen.ping.unicast.hosts 设置为集群其余节点地址
- discovery.zen.minimum_master_nodes 个别设定为 2
- path.data/path.log
- 除上述参数外再依据须要再减少其余动态配置参数
- 动静设定的参数有 transient 和 persistent 两种，前者再集群重启后会失落，后者不会，然而两种设置都会笼罩 elasticsearch.yml 的配置
jvm 内存
- 不要超过 31GB
- 余留一半给操作系统，用来做文件缓存
具体大小杜绝存储的数量来估算，为了性能，在内存和数据量间有一个倡议的比例
- 搜寻类我的项目的比例倡议在 1：16 以内
- 日志类我的项目比例在 1：48 – 1：96
- 假如总数据量大小为 1TB 3 个 node 1 正本 那么每个 node 存储的数量为 666GB，即 700GB，预留 20%，每个 node 存储 850GB 数据
- 如果是搜寻类，每个 node 内存大小为 850GB/16=53GB 大于 31GB 31*16=496 即每个 node 最多存储 496GB 数据 即起码须要 5 个 node
- 如果是日志类我的项目 每个 node 内存大小为 850GB/48=18GB 因而三个节点足够
写性能优化
指标是增大写的吞吐量 eps
客户端 多线程写
es 在高质量数据建模的前提下 次要在 refresh translog flush 之间做文章
升高 refresh 频率
- 减少 refresh_interval 升高实时性 增大每次 refresh 文档解决数，默认为 1s 设置为 -1 禁止主动 refresh
- 减少 index buffer size 参数为 indices.memory.index_buffer_size 动态参数 须要设定在 elasticsearch.yml 默认为 10%
升高 translog 写磁盘的频率 进步写效率 然而 升高了灾备的能力
- index.translog.durability 设置为 async index.translog.sync_interval 设置须要的大小 例如 120s 那么 translog 每 120s 写一次磁盘
- index.translog.flush_threshold_size 默认为 512mb 即 translog 超过大小时会触发一次 flush，那么调大该大小能够防止 flush 产生
- 设置正本数 0 写入结束后再减少
正当设计 shard 数 保障 shard 均匀分布在集群上 充分利用资源
- index.routing.allocation.total_shards_per_node 限定每个索引在每个 node 上可调配的总主副分片数
5 个 node 某索引有 10 个主分片 1 个正本 上述值该设置为多少？
- (10+10)/5=4
- 理论设置 5 个 搁置在 node 下线时 分片迁徙失败
读优化
- 高质量的数据建模是优化的根底
- 将须要通过 script 脚本动静计算的值进步筹备好作为字段存储在文档中
- 尽量使得数据模型贴近业务模型
设定 shard 数
- es 性能是线性扩大的 只须要测出一个 shard 的性能指标，而后依据需要算出须要几个 shard，例如单个 shard 写入 eps 是 10000 那么需要是 50000 则须要 5 个 shard
测试单个 shard
- 搭建与生产雷同配置的单节点集群
- 设定一个单分片零正本索引
- 写入理论生产数据进行测试 获取性能指标
- 针对数据进行查问申请 获取读性能指标
- 压测器具可选 esrally
- 搜寻场景 单个 shard 大小不要超过 15gb，如果是日志场景 单个 shard 不要超过 50GB shard 越大 查问性能越低
- 此时只有估算出索引总数居大小再除以单个 shard 大小也能够失去分片数
正文完
