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

ES 2.x bulk index 机械硬盘索引缓慢

Elasticsearch | 作者 chillyc | 发布于2017年09月18日 | 阅读数:4558

3 块企业SATA盘。 io util% 经常100%。 其中r/s 大约2000+, w/s 100左右。
如果没有r/s, w/s能到 300-500。 现在看内存, cpu,磁盘容量等都不是瓶颈。但是load较高大概50.

硬件。单机4个SATA, 其中三个SATA上各有一个es-data实例,该实例只使用自己所在的硬盘。 另外一个盘放master 实例和data的log. 现在设置索引只有3 shard, 1副本。每个es实例都使用cgroup做了隔离。
 
bulk 操作只有 index.  无update/delete等。模拟的数据JSON内容除了timestamp外基本无变化,自己生成的不重复id后写入ES.
 
初始启动ES时,写入速度8000-7000条/s,每条数据大概500B左右 运行1小时后开始逐渐降低。 运行十几个小时后,也就是几十条/s. 性能下降非常厉害。index.merge.scheduler.max_thread_count 设置为1 仍然无果。 

这十几个小时 ES 运行一直是Green.

详细设置信息:

index.number_of_shards: 3
index.number_of_replicas: 1
index.refresh_interval: 20s
index.load_fixed_bitset_filters_eagerly: false
index.cache.field.type: soft
index.cache.field.max_size: 500000
index.cache.field.expire: 5m
indices.fielddata.cache.size: 10%

cluster.routing.allocation.node_initial_primaries_recoveries: 30
cluster.routing.allocation.node_concurrent_recoveries: 20
indices.recovery.concurrent_streams: 8
indices.recovery.max_bytes_per_sec: 200mb
threadpool.index.type: fixed
threadpool.index.size: 100
threadpool.index.queue_size: 500
threadpool.bulk.size: 40
threadpool.bulk.queue_size : -1

index.merge.scheduler.max_thread_count: 1
index.merge.enabled: true
index.merge.policy.floor_segment: 20mb
index.translog.sync_interval: 60s
index.translog.fs.buffer_size: 16mb
index.translog.durability: ASYNC
cluster.routing.rebalance.enable: all
index.routing.rebalance.enable: REPLICAS
 
其实下面这一块内容增加与删除无影响。
index.merge.policy.floor_segment: 20mb
index.translog.sync_interval: 60s
index.translog.fs.buffer_size: 16mb
index.translog.durability: ASYNC
cluster.routing.rebalance.enable: all
index.routing.rebalance.enable: REPLICAS
另外 index.merge.enabled 设置为false 会明显导致创建索引变得更慢。
 
 
请问除了使用SSD,如何使用SATA盘让bulk 性能持续在8000-7000条/s? 如果使用SSD,测试是可以稳定到达 8000-7000条/s的。
 
已邀请:

novia - 1&0

赞同来自: chillyc

如果kennywu76说的不能起作用,我觉得是不是就是硬件问题了,我说下之前我们系统的问题,很你的现象类似。我们是历史数据入ES
1、刚开始是这样的(oss->metaq->中间服务->es):
两个客户端(中间服务),10个线程从metaq拉去数据,入ES(1master+4node,普通硬盘),我们的数据比较大,一条5-10K,当时的入库速度为10万/分钟,也是越来越慢,到后面几乎不能忍受。
 
2、进行了改造(oss->mr->es):
去掉了副本(写完再开启),两个map(相当于两个线程)写es,速度是快了,25万/10分钟,但还是越来越慢
 
3、申请费用,加配置(oss->mr->es)写es(3master->10node,高可用磁盘)
速度就没有问题了
 
废话多了,其实好些问题从软件上估计已经很难解决,只能拼硬件了
 

chillyc

赞同来自: novia

我可能找到问题了。原因是有一个磁盘出了问题。但是该磁盘4K读写测试和其他盘表现的一模一样。因为我每一个盘运行一个实例,在该盘上的thread bulk queue 特别大,其他的实例queue都是0. 最后我把这个盘上的实例停掉后重新测试,延迟问题就消失了。现在运行的非常稳定。

kennywu76 - Wood

赞同来自:

threadpool.bulk.queue_size : -1   这个设置有问题,索引速率跟不上的时候,请求会全部堆积在bulk queue里,内存消耗越来越高,恶性循环越来越越慢。  
 
index.translog.durability: ASYNC 这个设置应该是小写,确认下是否有生效。
 
单机上跑了多个实例,而每个实例只有一块SATA磁盘支持还是比较吃力的。 并发写入量很高的情况下,segment merge会比较吃力。 而过高的bulk线程池设置,以及无限的queue_size,可能会使情况更糟糕。 
 
另外确认下有无查询在执行。

weizijun - elasticsearch fan

赞同来自:

可能是运行久了单个shard太大?r/s远远大于w/s可能是在merge读取数据,可以看下节点的hot_threads,然后cpu的情况也可以描述下

要回复问题请先登录注册