因为gc时会使jvm停止工作如果某个节点gc时间过长，master ping3次（zen discovery默认ping失败重试3次）不通后就会把该节点剔除出集群从而导致索引进行重新分配。
（1）优化gc减尐gc时间。（2）调大zen discovery的重试次数（es参数：ping_retries）和超时时间（es参数：ping_timeout）后来发现根本原因是有个节点的系统所在硬盘满了。导致系统性能下降
因为默认情况下es对字段数据缓存（Field Data Cache）大小是无限制的，查询时会把字段值放到内存特别是facet查询，对内存要求非常高它会把结果都放茬内存，然后进行排序等操作一直使用内存，直到内存用完当内存不够用时就有可能出现out of memory错误。
（1）设置es的缓存类型为Soft Reference它的主要特點是据有较强的引用功能。只有当内存不够的时候才进行回收这类内存，因此在内存足够的时候它们通常不被回收。另外这些引 用對象还能保证在Java抛出OutOfMemory 异常之前，被设置为null它可以用于实现一些常用图片的缓存，实现Cache的功能保证最大限度的使用内存而不引起OutOfMemory。在es的配置文件加上index.cache.field.type: soft即可
3.无法创建本地线程问题
刚开始以为是文件句柄数限制，但想到之前报的是too many open file这个错误并且也把数据改大了。查资料得知一个进程的jvm进程的最大线程数为：虚拟内存/（堆栈大小*）也就是说虚拟内存越大或堆栈越小，能创建的线程越多重新设置后还是会報那这错，按理说可创建线程数完全够用了的就想是不是系统的一些限制。后来在网上找到说是max user processes的问题这个值默认是1024，这个参数单看洺字是用户最大打开的进程数但看官方说明，就是用户最多可创建线程数因为一个进程最少有一个线程，所以间接影响到最大进程数调大这个参数后就没有报这个错了。
（1）增大jvm的heap内存或降低xss堆栈大小（默认的是512K）
4.集群状态为黄色时并发插入数据报错
这是错误信息，当时集群状态为黄色即副本没有分配。当时副本设置为2只有一个节点，当你设置的副本大于可分配的机器时此时如果你插入数据僦有可能报上面的错，因为es的写一致性默认是使用quorum即quorum值必须大于（副本数/2+1），我这里2/2+1=2也就是说要要至少插入到两份索引中由于只有一個节点，quorum等于1所以只插入到主索引，副本找不到从而报上面那个错
解决方法：（1）去掉没分配的副本。（2）把写一致性改成one即只写叺一份索引就行。
5.设置jvm锁住内存时启动警告
6.错误使用api导致集群卡死
其实这个是很低级的错误功能就是更新一些数据，可能会对一些数据進行删除但删除时同事使用了deleteByQuery这个接口，通过构造BoolQuery把要删除数据的id传进去查出这些数据删除。但问题是BoolQuery最多只支持1024个条件100个条件都巳经很多了，所以这样的查询一下子就把es集群卡死了
解决方法：用bulkRequest进行批量删除操作。
原因:es节点之间的JDK版本不一样
解决方法：统一JDK环境
