使用 450K 文档进行 ElasticSearch 索引 - 性能答案

【问题标题】：ElasticSearch indexing with 450K documents - performance使用 450K 文档进行 ElasticSearch 索引 - 性能
【发布时间】：2017-02-19 17:22:28
【问题描述】：

我们在 AWS 上有 ElasticSearch (1.5)（t2.micro，2 个实例，每个实例有 10GB SSD 存储）和一个 MySQL，有大约 450K 相当大/复杂的实体。

我正在使用 python 从 MySql 中读取数据，序列化为 JSON 并 PUT 到 ElasticSearch。有 10 个线程同时工作，每个线程同时 PUT 大量 1000 个文档。

总共约 450K (1.3GB) 文档，处理并发送到 ElasticSearch 大约需要 20 分钟。

问题是其中只有大约 85% 被编入索引，而其余部分则丢失了。当我将文档数量减少到约 100K 时，它们都会被编入索引。

查看 ElasticSearch AWS 监视器，我可以看到 CPU 在索引时达到 100%，但它没有给出任何错误。

在这里找到瓶子的最佳方法是什么？我希望它快一点，但不能丢失任何文件。

编辑。我每隔几分钟再次运行它检查 /_cat/thread_pool?v 的输出。在 441400 中索引 390805。在下面的线程池中：

host             ip            bulk.active bulk.queue bulk.rejected index.active index.queue index.rejected search.active search.queue search.rejected 
<host> x.x.x.x           1         22            84            0           0              0             0            0               0 
<host> x.x.x.x           1         11            84            0           0              0             0            0               0 
<host> x.x.x.x           1         29            84            0           0              0             0            0               0 
<host> x.x.x.x           1         13            84            0           0              0             0            0               0 
<host> x.x.x.x           0          0            84            0           0              0             0            0               0 
<host> x.x.x.x           1         17            84            0           0              0             0            0               0 
<host> x.x.x.x           0          0            84            0           0              0             0            0               0

编辑 2

host             ip            bulk.active bulk.queue bulk.rejected index.active index.queue index.rejected search.active search.queue search.rejected 
<host> x.x.x.x           0          0            84            0           0              0             0            0               0

编辑 3

$ curl https://xxxxx.es.amazonaws.com/_cat/thread_pool?v&h=id,host,ba,bs,bq,bqs,br,‌bl,bc,bmi,bma
[1] 15896
host             ip            bulk.active bulk.queue bulk.rejected index.active index.queue index.rejected search.active search.queue search.rejected 
<host> x.x.x.x           0          0            84            0           0              0             0            0               0

^^ 复制/粘贴我返回的内容

编辑 4

$ curl 'https://xxxxx.es.amazonaws.com/_cat/thread_pool?v&h=id,host,ba,bs,bq,bqs,br‌,‌bl,bc,bmi,bma'
<html><body><h1>400 Bad request</h1>
Your browser sent an invalid request.
</body></html>

什么都没有

编辑 5

id   host             ba bs bq bqs br bmi bma bl br    bc 
n6Ad <host>  0  1  0  50 84   1   1  1 84 25821

当我改变参数的顺序时，它以某种神秘的方式工作

【问题讨论】：

请使用您从以下获得的输出更新您的问题：curl localhost:9200/_cat/thread_pool?v 如果您看到bulk.rejected 列 > 0，那么您的一些批量呼叫被拒绝，因为您发送它们的速度比您的发送速度快服务器可以处理。
感谢Val的评论，请检查我的编辑^^
请添加以下标题curl localhost:9200/_cat/thread_pool?v&h=id,host,ba,bs,bq,bqs,br,bl,bc,bmi,bma
你能帮我解释一下这些值吗？
您可以查看 Kinesis Firehose 以将数据摄取到 ES 中

标签： python mysql amazon-web-services elasticsearch

【解决方案1】：

我怀疑 EC2 是您的瓶颈。基于the way burstable instances are allocated CPU，t2.micro 每小时累积 6 个 CPU 积分。

因此，在您的第一个小时内，您的 Elasticsearch 节点将能够以 100% 的速度运行一个 vCPU，最多 6 分钟，然后以未指定的较低资源分配“上限”（假设小于 vCPU 10% 的实例配额）。

Elasticsearch 在索引期间最有可能受 CPU 限制。如果索引进程发送批量请求的速度快于实例可以接收的速度（由于受 CPU 限制...在配额范围内，或者在前 6 分钟突发后之后超出配额），这些请求将队列。一旦队列饱和，Elasticsearch 将开始拒绝请求。

这可能有助于解释为什么您能够毫无问题地索引 100k 文档（不到 6 分钟？），而您的完整集合（约 450k）遇到困难。

如果您的集群在编制索引期间受 CPU 限制，并且批量请求被拒绝，您需要：

在索引期间增加集群节点可用的计算资源

或
限制您的索引器以跟上您的集群摄取容量。

在决定触发之前，您可以通过运行 thread_pool 请求来检查队列中有多少批量请求（可能是队列总大小的百分比），从而构建一个对较小节点类型更具弹性的索引器下一个批量索引请求。

【讨论】：