百姓网 Elasticsearch 2.x 升级之路

4)2.x 你仍然可以 Disable doc_values,设置一个较大的 heap.只要没有较大的 GC 问题,选择 disable doc_values 是可以的,而且带来的好处是索引较小.这是一个平衡选择,大家可以根据平时使用情况进行调整.我们选择了 disable doc_values 以减少索引大小.

5、GC 各种挂、挂、挂.

在 1.x 升级到 2.x 的过程,基于集群只能滚动式升级,这决定 1.x 和 2.x 集群是同时共存.而在升级过程中,不幸躺着中枪,频繁遇到 GC 问题,几乎导致升级失败.

首先我们尝试了进行 GC 调优,CMS,G1,调整 heap size,heap NEW size ….,各种策略均告失败.调整 thread pool 各项参数,对 query:size 过大数字也进行调整,以减少 GC 压力,这些调整也均失效.

具体表现为,运行一段时间后,集群中某些 Node 的 CPU Usage 会突然上升,最后 JVM 保持在 100% CPU Usage,集群 Node 因为长期下线,被集群踢出,如果运气好,Node 还会回来,大部分情况下它就保持在 100% CPU Usage 不死不活.

检查日志,并无 OOM,而显示 GC 问题很大,在几次 CMS GC (new heap) 后,发生 Full GC,并且 Heap 使用率一直保持 90% 左右,GC 进入死循环.

一开始,判断是 GC 问题,故而一直进行 GC 调优,未果.

当我们遇到 JVM GC 时,很可能并非 GC 策略本身问题,而可能是应用的 BUG.最后,我们不得不另寻出路.

1)对 Cache (Static 配置,需要配置在 elasticsearch.yml 并重启) 和 Circuit breaker 配置进行调整.如下：

Static 配置：

indices.queries.cache.size

indices.cache.filter.size

indices.queries.cache.size

indices.memory.index_buffer_size

Circuit breaker 配置：

indices.breaker.request.limit

indices.breaker.fielddata.limit

indices.breaker.total.limit

前者和后者中相关的配置需要保持前者小于后者.

调整这些数据,未果.

2)Mapping 过大?

我们的 Mapping 确实比较大,因为业务处理逻辑复杂,各种名字的字段没有明确的限制,所以 Mapping 是比较大的.在 Mapping 很大的时候,当一个新的字段进行索引,每个索引都要进行 mapping 更新,可能会导致 OOM.不过我们观察到我们的 GC 问题和索引更新并没有很明显的联系,因为我们在进行索引初始化时,快速 Bulk 索引也只是 LA 比较大,并无 GC 问题,再一个在 1.x mapping 也没有什么问题.

3)Shards 太多?

shards 过多,也是可能导致 GC 问题的.因为每个 shard 的内存使用控制变得复杂.尽管我们某些集群的 shards 数量较多( shards 90 * 2 = 180 个 shard),但尝试调整或合并 Shards,均告无果.

4)Doc_values 和 fielddata cache 选择

因为 GC 这种问题,所以我们尝试减少 JVM 的内存使用,降低 GC 压力.启用 doc_values后,Heap 内存占用变小,但不能解决这个问题.减小 Heap 大小,以减轻 GC 压力,也无法解决这个问题.

5) Filtered Query 兼容之坑

我们对 1.x 和 2.x 集群加上了版本区分.在 2.x 的情况下,我们对查询进行了强制修改.修改办法就是上面提到的 Filtered Query 变更.即取消 filtered 而使用 bool 来进行代替.GC 问题得到缓解.

6)Aggerations histogram?

我们经过仔细对比 1.x 和 2.x,对于 aggs histogram 的默认值变化(doc_min_count从1到0),一开始并没有重视,后来显式的设置这个参数为 1.GC问题得到解决.

上面的 5)6) 就是 GC 问题两个很深的坑.

虽然他们算不上是 BUG,然而在 filtered query 只是 deprecated,而不是不能使用的情况下,这也太坑人了,遇到需要多集群滚动式升级的(比如我们),可能就会沿用 filtered query,以便能平滑升级,然后就会掉进深坑而不能自拔.

而 6)也算不上是 BUG,不过对于 doc_min_count = 0,大概率会触发 GC,使用任何 GC 策略都不能正常使用.

三、优化或建议

1、Lucene version 在初期版本要显式的在 mapping::settings 中配置.后来的版本没有问题了.建议升级到较高版本以避免这种问题.

2、 aggerations 尽可能不要用在 analyzed fields,原因是 analyzed fields 是没有 doc_values的,另外 analyzed fields 分词之后,你进行 aggerations 也只能得到 term 的统计结果.

3、如果修改文档是增量的,并且不会带来数据覆盖问题,建议使用 update API(或 bulk update API),可接受部分数据更新,而不需要一个完整文档.

4、thread pool 调整.

如果一台服务器内存较大或者因为多集群原因需要配置多个 Elasticsearch JVM node,建议调整默认的 threadpool.search.size (默认值：int((available_processors * 3) / 2) + 1),比如默认值为 24,此时这台机器有 2 JVM node,可以根据各 node 大致的访问量、访问压力在 24 / 2 = 12 上下调整.如果更配置更多的 JVM 以有效利用 CPU 和内存,需要进行这个调整.否则 JVM 可能奔溃而无法启动.

5、count api (search api with size 0)

Count API 在某种情况下是很有效,比如当你只想获得 Total Count 的时候,可以使用这个 API.

不过,2.1 以后已经使用 search API 并设置 size = 0 来代替了.新版本中 Elasticsearch Java 代码中 Count API 已经去除,但是应用层面 _count 还是保留的.

6、timeout 参数 2.x 必须加上 s,如 ：? timeout = 3s

四、百姓之道

0、基本优化: 包括 硬件(CPU、Memory、SSD)、JVM 及其版本选择(Heap size,GC,JDK8)、系统配置(File Descriptors、VM/Virtual memory、Swap、Swappiness、mlockall).

我们使用多核服务器和大内存,一定程度上可以弥补非 SSD 磁盘.

一台服务器多个 JVM,版本为 JDK8；Heapsize 一般为 30G 以内,根据不同用途、索引大小和访问压力,Heapsize 有 5、10、20、30G 的不同配置,Heap NewSize 配置比较激进,通常大于 Heapsize 的一半；GC 选择 CMS GC.

1、routing : UID,first_category,city + second_category

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!