Elasticsearch 批量更新极慢答案

【问题标题】：Elasticsearch bulk update is extremely slowElasticsearch 批量更新极慢
【发布时间】：2017-08-02 00:01:29
【问题描述】：

我将每个索引约 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 此处的建议，我为加快集群中的索引速度所做的优化是

设置“indices.store.throttle.type”：“无”
索引“refresh_interval”：“-1”

我在 4 个 d2.8xlarge EC2 实例上运行我的集群。我为每个节点分配了 30GB 的堆。虽然更新正在进行，但几乎没有使用任何 cpu，负载也非常少。

尽管更新非常缓慢。是否有一些我遗漏的非常明显的东西导致了这个问题？在查看线程池数据时，我发现处理批量操作的线程数一直很高。

在这个问题上的任何帮助都会非常有帮助

提前致谢

【问题讨论】：

您使用什么语言？听起来你在某处有内存泄漏。也许是一个打开的文件？
我也面临同样的问题。我们能解决缓慢的问题吗？

标签： elasticsearch logstash

【解决方案1】：

这里有几个排除方法可供尝试。

内存压力

使用 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 表示顶部和 iowait 建议，我敢打赌，您会在该区域看到超过 40 的一些值。话虽如此，我使用的是 2 数据 3 主节点设置，主要是普通弹性设置，可以索引大约 1200 文档/秒，包含 50 个字段和总共 200 个字节。这些磁盘是 EBS（未优化 IOPS）。

【解决方案2】：

在使用 elasticsearch 6.0 版时，我们遇到了完全相同的问题，即 aws 更新缓慢，罪魁祸首是 I/O 缓慢。相同的数据在本地测试堆栈上更新插入完全没问题，但一旦在 ec2 堆栈上的云中，在最初的快速插入仅持续几分钟后，一切都消失了。

本地测试堆栈在内存和 CPU 方面是低规格服务器，但包含 SSD。

s3 堆栈是默认 gp2 300 IOPS 的 EBS 卷。

以 3000 IOPS 将卷转换为 io1 类型解决了这个问题，一切都回到了正轨。

【讨论】：

【解决方案3】：

我正在使用 amazon aws elasticsearch service version 6.0 。我需要从 json 文件序列到 elasticsearch 的大量写入/插入 100 亿个项目。 elasticsearch-py 批量写入速度大部分时间确实很慢，偶尔会高速写入。我尝试了各种方法，例如将 json 文件拆分为更小的部分，多进程读取 json 文件，parallel_bulk 插入到 elasticsearch 中，没有任何效果。最后，在我升级 io1 EBS 卷后，10000 写入 IOPS 一切顺利。

【讨论】：