Follow me on GitHub

elasticsearch调优之Merge

0x01 背景

天苍苍,野茫茫,过完春节就要忙,服务压力跟不上,用服务器数量来抗.多数人认为这个套路能简单粗暴的解决问题,当然我也不例外.

春节刚过,我司流量跟着上来了,作为基础的日志处理服务,需要保障流量上涨后的性能和稳定.重头就在es集群性能.于是着手对集群整体进行硬件上的资源扩充.

  • 提高服务器配置和数量 从原来的8台机器扩充到11台机器(这里指的是data node),从原来的 24 core/128g mem/4T * 12 data 扩充到 32 core/128g mem/1T * 24 data.(不要羡慕我司的土豪,有钱就是任性!).

  • 增加消费者(index端) 部分日志处理从 logstash 换成 hangout ( java实现的类Logstash几个常用input/filter/output,在效率上面有很大提升,感谢@携程同学的开源) 并调优相关写入策率: flush_interval , bulk_size 等调整

  • 性能预估 原来集群的配置可以抗住每天的20亿条的日志写入,峰值能到6w--8w条/s,读取性能每天pv在10w+左右,当然以上数据还不是集群的瓶颈点,扩展后的集群感觉怎么也能在原来的基础上写入和读取性能翻翻了.

根据以上的部署调整,心想万事大吉,只欠大流量的东风.

0x02 实践出真知

随着流量上涨,日志量的上涨后,上述服务跑几天后,发现事实却没有想想的那么完美.前端展示时常刷不出统计监控数据,具体表现为集群的写入数据跟不上,查看监控发现,写入情况实时监控出现经常发生写入性能陡降: zb陡降图 zabbix_write

看到上面的问题后,心中犹如飘过无数个草泥马,非常的不友好了..... 于是赶紧通过bigdesk排查下是什么原因. bigdesk中表现出集群中有一两台服务器的bulk队列出现bulk的count数居高不下,时间一长随之而来bulk的queue也随之增大,从而阻塞整个集群的写入性能:

bulk拥堵图 bulk_quene

当然也可通过命令查看各个节点的详细信息:

curl -sXGET "http://localhost:9200/_cat/thread_pool?v"

似乎有点头目了,继续追查,马上去bulk拥堵的data节点上去翻日志查看,出现大量info提示: info图 info

感觉发现了问题所在,google了下上面的日志,得出的结论是,es集群的磁盘有瓶颈,是因为merge速率跟不上数据进来的速率了,造成了写阻塞.有人建议用ssd,就说我司比较土豪,但是还不至于土豪到随便就来10台ssd的机器让我把玩吧. 开始怀疑人生了,难道这么NB配置的服务器还不能满足现在的需求吗?于是开始登陆到相应服务器上看看各项性能负载情况,什么cpu load阿,iostat阿,都查了一圈,结果整台机器的负载连10%都不到,不是机器负载的问题阿.开始有点蒙圈了.

自己整不明白请外援,请教了下 @wood 叔叔,@wood 叔叔授人以渔,发来一篇官方文档:Elasticsearch Reference [1.7] » Index Modules » Store,其中 Store Level Throttlingedit 段已经指出相应问题所在.

  • 官方文档解读 es的merge process是一个异步方式合并数据,而减少对索引/搜索速度影响,但是在一些性能比较低(IO)的服务器上,数据的merge相对于系统资源来说是比较昂贵的,主要占用是IO资源,当IO出现瓶颈的话,就会对索引/搜索产生影响。 存储模块可以对merge的速度进行动态的设置限制调整, 当然调整的越大就会对磁盘IO资源消耗越多,即:
indices.store.throttle.type: "merge" （默认为merge）
indices.store.throttle.max_bytes_per_sec: "20mb" (默认20mb)

当然以上参数可以针对某个index进行调整,也可以针对整个集群做上述参数的调整,增加这个参数的前提条件是,磁盘io目前并没有压力,如果IO uitil%已经很高,CPU 的IO wait很高,那么就说明磁盘IO有瓶颈了,增加这个参数也没有用。 此问题其实包含es的1.x版本.看文档中2.x版本没有相关内容的阐述(手头也没测试过2.x版).

0x03 调优设置

进行对集群的 Store Level Throttlingedit 相关参数进行调整设置,设置前提是io没有瓶颈,当然调整后最好监控看下io负载.

curl -XPUT http://localhost:9200/_cluster/settings -d '{
    "persistent": {
                "indices.store.throttle.type": "merge",
                "indices.store.throttle.max_bytes_per_sec": "100mb"
    }
}'

调整之后看下集群的写入性能监控,性能猛增,bulk等队列也很平稳正常: zabbix_write

0x04 其他相关

ES的版本迭代非常快, 相信一些性能优化问题后续版本也越好越好,越来越强大。对于性能方面调整首先需要做的就是监控,强大的的监控,对es的各个细节进行各个维度的监控,这样才能有迹可查。另外其实官方文档写的已经非常详细了,多半问题或是配置相关的调优官方文档都给了相关解释,如果出现问题可以先从官方文档下手,或是结合在Github的issue list里搜索一下,看是否使用的版本有其他人反映同样的问题,多半能解决问题.

Comments !