内存分配优化
每个节点都有125G的内存
内存设置规则
32GB是ES一个内存设置限制，那如果你的机器有很大的内存怎么办呢？现在的机器内存普遍增长，你现在都可以看到有300-500GB内存的机器。
首先，我们建议编码使用这样的大型机
其次，如果你已经有了这样的机器，你有两个可选项：
你主要做全文检索吗？考虑给Elasticsearch 32G内存，剩下的交给Lucene用作操作系统的文件系统缓存，所有的segment都缓存起来,会加快全文检索
你需要更多的排序和聚合？你希望更大的堆内存.你可以考虑一台机器上创建两个或者更多ES节点,而不要部署一个使用32+GB内存的节点.仍然要 坚持50%原则,假设 你有个机器有128G内存,你可以创建两个node,使用32G内存.也就是说64G内存给ES的堆内存,剩下的64G给Lucene
如果你选择第二种,你需要配置cluster.routing.allocation.same_shard.host:true.这会防止同一个shard的主副本存在同一个物理机上（因为如果存在一个机器上,副本的高可用性就没有了）
当然,内存对于Elasticsearch来说绝对是重要的,用于更多的内存数据提供更快的操作,而且还有一个内存消耗大户-Lucene
Lucene的设计目的是把底层OS里的数据缓存到内存中。Lucene的段是分别存储到单个文件中的，这些文件都是不会变化的，所以很利于缓存,同时操作系统也会把这些段文件缓存起来,以便更快的访问
Lucene的性能取决于和OS的交互，如果你把所有的内存都分配给Elasticsearch,不留一点给Lucene,那你的全文检索性能会很差的
最后标准的建议是把50%的内存给elasticsearch,剩下的50%也不会没有用处的,Lucene会很快吞噬剩下的这部分内存用于文件缓存
不要超过32G
swapping是性能的坟墓
这是显而易见的,但是还是有必要说的更清楚一点,内存交换到磁盘对服务器性能来说是致命的.想想看一个内存的操作必须是快速的
如果内存交换到磁盘上，一个100微秒的操作可能变成10毫秒，再想想那么多10微秒的操作时延累加起来。不难看出swapping对于性能是多么可怕。
最好的办法就是在你的操作系统中完全禁用swapping.这样可以暂时禁用：
swapoff -a
为了永久禁用它，你可能需要修改/etc/fstab文件，这要参考你的操作系统相关文档。
如果完全禁用swap，对你来说是不可行的。你可以降低swappiness 的值，这个值决定操作系统交换内存的频率。这可以预防正常情况下发生交换。但仍允许os在紧急情况下发生交换。
对于大部分Linux操作系统，可以在sysctl 中这样配置：
vm.swappiness = 1
备注：swappiness设置为1比设置为0要好，因为在一些内核版本 swappness=0会引发OOM（内存溢出）
简单地说这个参数定义了系统对swap的使用倾向，默认值为60，值越大表示越倾向于使用swap。可以设为0，这样做并不会禁止对swap的使用，只是最大限度地降低了使用swap的可能性。
通过sysctl -q vm.swappiness可以查看参数的当前设置
修改参数的方法是修改/etc/sysctl.conf文件，加入vm.swappiness=xxx，并重起系统。这个操作相当于是修改虚拟系统中的/proc/sys/vm/swappiness文件，将值改为XXX数值。
如果不想重起，可以通过sysctl -p动态加载/etc/sysctl.conf文件,但建议这样做之前先清空swap。
最后,如果上面的方法都不能做到,你需要打开配置文件中的mlockall开关,它的作用就是运行JVM锁住内存,禁止OS交换出去.在elasticsearch.yml配置如下：
bootstrap.mlockall: true
配置文件
ES集群数据的迁移
快照方式
必须先停止es服务.迁移速度快,适用数据量大的场景
1.先配置源es集群的快照目录。重新启动es服务
2.注册repo
curl -k -XPUT -u elastic:bbbb'https://11.223.35.209:9200/_snapshot/my_backup' -H 'Content-Type: application/json' -d '{ "type": "fs", "settings": { "location": "/app/taishi/esrepo", "compress": true } }'