es优化

1. Mapping中能设置成keyword ，优先设置为keyword。这样lunece就不会大量的分词，加长插入时间。

2. PUT /speedtest8/_settings

{

    "number_of_replicas": 0,

    "refresh_interval" :"60s"

}先将副本数设置为0.如果不需要实时取得数据， 可以修改refresh 修改刷新时间。这边的refresh指的是，过多长时间，讲存入内存的索引，写入到磁盘上，默认是一秒，在某个时间段内插入大量的索引的场景下使用默认的浪费资源。

3.锁住swap，这会影响es性能（或者修改elasticsearch.yml 添加配置bootstrap.memory.lock）设置完成后要去修改一个配置文件，如果不修改es会报错，需要修改的内容就在报错里面。

4.全部用物理机，不能用虚拟机。虚拟机大大影响效率（巨影响）

5.在jvm.option中xmx 给整个内存的一半 但是不能超过32g，超过32g java指针将不是压缩的，反而会慢.

6.对translog进行优化。要知道当插入信息写入内存的时候，es怕突然断点或等等情况。导致缓存中数据还没有写入磁盘上，用了一个translog作为监控（每次释放时间啊，异步等等）保证了es数据的原子性。

7.合理建立分片。分片过多影响查询速度，每个分片最多放置2的31次放文档数目（integer.max）。每段时间新建新的索引，（就算插满了 集群还是green，就是不写入，气不气，这个坑日志里会有显示。翻译过来就是每个分片的document不能大于21亿多少多少的）

8.64g内存远远比32G内存的机器稳定。将一半内存分给es后，剩下来的内存很快会被lunece占用，做倒排索引，分词等等。(64G内存的机器， 将32G内存分给es。64G机器相比较于32G的机器，当用bulkprocess批量插入的时候。64G机器波动在1秒左右，32G波动在5秒以上，有时候能达到20多秒)。（2020 10/05 此处怀疑波动是因为元空间膨胀，导致堆大小被压缩）

9.rebalance ：none 怕陡然某台机器挂掉了。然后这台机器的工作交给其他机器。本来就在崩溃的边缘了，死了一个不能死全部吧。这会导致es雪崩。所以当es某个datanode挂掉可以在线设置这个。然后空闲时间在改回来。

10,。每台datanode节点，每多1G堆内存，则分片数量可以多20-25以下。每个分片最好分配50G以下的数据