1.由 gc 引起节点异常
问题:
因为 gc 时会使 jvm 停止工作,如果某个节点 gc 时间过长,master ping 3次(zen discovery默认 ping 失败重试 3 次)不通后就会把该节点剔除出集群,从而导致索引进行重新分配。
解决方法:
1. 优化gc,减少gc时间。
2. 调大zen discovery 的重试次数(es参数:ping_retries)和超时时间(es参数:ping_timeout)
后来发现根本原因是有个节点的系统所在硬盘满了。导致系统性能下降。
2. out of memory 错误
问题:
因为默认情况下es对字段数据缓存(Field Data Cache)大小是无限制的,查询时会把字段值放到内存,特别是 facet 查询,对内存要求非常高,它会把结果都放在内存,然后进行排序等操作,一直使用内存,直到内存用完,当内存不够用时就有可能出现 out of memory 错误。
解决方法:
1. 设置 es 的缓存类型为 Soft Reference,它的主要特点是据有较强的引用功能。只有当内存不够的时候,才进行回收这类内存,因此在内存足够的时候,它们通常不被回收。另外,这些引用对象还能保证在 Java 抛出 OutOfMemory 异常之前,被设置为 null。它可以用于实现一些常用图片的缓存,实现 Cache 的功能,保证最大限度的使用内存而不引起 OutOfMemory。在 es 的配置文件加上 index.cache.field.type: soft 即可。
2. 设置 es 最大缓存数据条数和缓存失效时间,通过设置 index.cache.field.max_size: 50000 来把缓存 field 的最大值设置为 50000,设置 index.cache.field.expire: 10m 把过期时间设置成10分钟。
3.无法创建本地线程问题
问题:
es恢复时报错: RecoverFilesRecoveryException[[index][3] Failed to transfer [215] files with total size of [9.4gb]]; nested: OutOfMemoryError[unable to create new native thread]; ]]
刚开始以为是文件句柄数限制,但想到之前报的是too many open file这个错误,并且也把数据改大了。查资料得知一个进程的jvm进程的最大线程数为:虚拟内存/(堆栈大小*1024*1024),也就是说虚拟内存越大或堆栈越小,能创建的线程越多。重新设置后还是会报那这错,按理说可创建线程数完全够用了的,就想是不是系统的一些限制。后来在网上找到说是max user processes的问题,这个值默认是1024,这个参数单看名字是用户最大打开的进程数,但看官方说明,就是用户最多可创建线程数,因为一个进程最少有一个线程,所以间接影响到最大进程数。调大这个参数后就没有报这个错了。
解决方法:
1. 增大 jvm 的 heap 内存或降低 xss堆栈大小(默认的是512K)。
2. 打开/etc/security/limits.conf ,把soft nproc 1024 这行的 1024 改大就行了。