我正在将每个索引的大量日常数据~160GB索引到elasticsearch中。我面临这种情况,我需要用少量数据(~16GB)更新索引中的几乎所有文档,格式为
id1,data1
id1,data2
id2,data1
id2,data2
id2,data3
.
.
.
我的更新操作开始以每秒16000行的速度发生,并且在5分钟内达到每秒1000行,并且在此之后不会上升。此16GB数据的更新过程目前比我160GB的整个索引编制所需的时间更长
我的更新操作的conf文件目前如下所示
output
{
elasticsearch {
action => "update"
doc_as_upsert => true
hosts => ["host1","host2","host3","host4"]
index => "logstash-2017-08-1"
document_id => "%{uniqueid}"
document_type => "daily"
retry_on_conflict => 2
flush_size => 1000
}
}
我根据https://www.elastic.co/guide/en/elasticsearch/guide/current/indexing-performance.html中的建议为我的群集加速索引所做的优化是
我在d2.8xlarge EC2实例的4个实例上运行我的集群。我已经为每个节点分配了30GB的堆。 虽然更新正在发生,但几乎没有使用任何CPU,负载也很少。
尽管所有更新都非常缓慢。是否有一些非常明显的东西,我错过了导致这个问题?在查看线程池数据时,我发现处理批量操作的线程数量一直很高。
对此问题的任何帮助都非常有帮助
提前致谢
答案 0 :(得分:2)
在这里尝试一些规则。
记忆压力
拥有244GB的RAM,这不太可能,但你仍然可以检查出来。在您的平台的JDK中找到jstat
命令,尽管有一些可视化工具。您想要检查Logstash JVM和ElasticSearch JVM。
jstat -gcutil -h7 {PID of JVM} 2s
这将为您提供该JVM工作时各种内存池,垃圾收集计数和GC计时的读数。它将每2秒更新一次,并且每7行打印一次标题。在FCT
中花费过多的时间表明你没有为HEAP服务。
I / O压力
d2.8xlarge是一个密集存储实例,对于高度随机的小块工作负载可能不太好。如果您使用的是Unix平台,top
会告诉您在IOWAIT状态下花费了多少时间。如果它很高,那么您的存储空间不会达到您发送的工作量。
如果是这种情况,您可能需要考虑配置的IOP EBS实例而不是实例本地的实例。或者,如果您的内容适合,请考虑i3
高I / O实例系列中的实例。
Logstash版本
您没有说明您正在使用的Logstash版本。作为StackOverflow,你可能会使用5.2。如果是这种情况,这不是一个排除规则。
但是,如果您在2.x系列中使用了某些内容,则可能需要先将-w
标志设置为1,然后逐步提升。是的,这是单线程的。但是ElasticSearch输出在2.x系列中有一些并发问题,这些问题在5.x系列中有很大的修复。
答案 1 :(得分:0)
使用elasticsearch版本6.0,我们在aws上有一个完全相同的缓慢更新问题,罪魁祸首是I / O缓慢。相同的数据在本地测试堆栈上完全正常,但是一旦在ec2堆栈上的云中,在最初爆发的快速插入仅持续几分钟后,一切都在死亡。
就内存和CPU而言,本地测试堆栈是一个低规格的服务器,但包含SSD。
s3堆栈是EBS卷,默认gp2 300 IOPS。
将卷转换为具有3000 IOPS的io1类型解决了这个问题,一切都恢复正常。
答案 2 :(得分:0)
我正在使用Amazon AWS Elasticsearch Service 6.0版。我需要从json文件序列到Elasticsearch进行大量写入/插入操作,以搜索100亿个项目。大部分时间,elasticsearch-py批量写入速度确实很慢,偶尔也可以高速写入。我尝试了各种方法,例如将json文件拆分成较小的部分,多进程读取json文件,将parallel_bulk插入elasticsearch中,没有任何效果。最终,在升级io1 EBS卷之后,使用10,000个写入IOPS可以顺利进行所有操作。