使用 shuf 来打乱一个文件中的行或是选择文件中一个随机的行。

ES5.4 document missing bulk写入性能

Elasticsearch | 作者 240475588 | 发布于2017年08月02日 | 阅读数:5006

在5.4环境下做全量,每批写入(bulk5000),5.4环境耗时10S左右,1.7 环境耗时1S。这是为什么呢,每批的数据写入会有大量的 document missing异常这个是已经确认的,难道5.4的环境 document missing会有什么操作导致性能下降。有没有避免的方案。transport.tcp.compress TCP压缩已经开启(原本以为是这个地方的问题,结果不是)
下面是ES5.4日志和集群信息:(ES1.7环境的毫秒数是700ms-1000ms,5.4日志的毫秒数看图,差距太大了)
f693a1c5b05a4c65bef7741b1b93a07b.png


QQ图片20170802111400.png


QQ图片20170802111416.png

 
已邀请:

240475588

赞同来自:

硬件环境都是一样的,求大神指点,卡很久了

luyee2010

赞同来自:

bulk 5000  单个request多大? tps多少?

kennywu76 - Wood

赞同来自:

1.7也有大量的docment missing异常吗?
 
大量这种异常的出现应该是会影响写入性能的,如果你是通过bulk数据做更新,考虑使用upsert操作。

240475588

赞同来自:

QQ图片20170802142949.png

代码是这样的,用painless脚本

kennywu76 - Wood

赞同来自:

如果用的硬件一摸一样,集群参数设置一样,数据的shard分布一样,mapping一样,script更新的逻辑也一样, 那我能想到的两个版本在写入性能上的差异可能有下面这些:
  1. 脚本groovy和painless的不同,但是根据官方文档说明,painless应该好于groovy,所以可能性不大。 但是为了排除这个可能性,你可以将5.4配置使用groovy script engine,看性能是否有改善。
  2. 1.7的索引translog是异步定期持久化到磁盘的,5.4是per request,如果bulk并发量高,磁盘io性能比较差,效率比1.7要差。 是否有磁盘io瓶颈可以监控磁盘性能得出结论。 如果确认是磁盘io方面有差异, 可以尝试更改5.4里索引的translog持久化为async,并适当增加sync周期(默认5s)。 然后对比看是否有改善。 对应的索引设置项分别是: index.translog.durability: "async"以及index.translog.sync_interval: "5s"

 
如果还不能找出原因,就只能到ES官方论坛寻求帮助了。

catkinsli

赞同来自:

5000大概最多几十MB bulk性能是有下降的 你的5000不是相同的data数据  你最好换成相同的data  看性能  

240475588

赞同来自:



 

240475588

赞同来自:

ed54c59ae7bc49bd8dc1cc45cc151e6c.png

 

240475588

赞同来自:

磁盘io也不高
0b628e383c954e8393ad499b555bac8a.png

 

240475588

赞同来自:

"roles" : [ "master", "data", "ingest" ]

"client" : { "type" : "node" },
我集群三台都是这样的配置

240475588

赞同来自:

9f55dfad4a7e410bb64f4f02f7ad1bed.png


更新过的批次和没更新过的批次性能不是一个量级的

geekLhl

赞同来自:

大哥,请问最后你这个如何解决的,遇到了相同的问题。

要回复问题请先登录注册