gpt4 book ai didi

python - 450K 文档的 ElasticSearch 索引 - 性能

转载 作者:行者123 更新时间:2023-11-29 11:14:27 25 4
gpt4 key购买 nike

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

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

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

问题是只有大约 85% 的内容被索引,其余的都丢失了。当我将文档数量减少到约 100K 时,它们都会被索引。

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

在这里找到瓶子的最佳方法是什么?我想要快速但又不能丢失任何文件。

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

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

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

最佳答案

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

因此,在启动的第一个小时内,您的 Elasticsearch 节点将能够以 100% 的速度运行一个 vCPU 最多 6 分钟,然后才会被“限制”在未指定的较低资源分配(假设小于实例配额(vCPU 的 10%)。

Elasticsearch 在索引过程中很可能会受到 CPU 限制。如果索引进程发送批量请求的速度快于实例摄取的速度(由于 CPU 限制...在配额内,或在突发的前 6 分钟后超出配额),这些请求将队列。一旦队列饱和,Elasticsearch 将开始拒绝请求。

This may help explain why you're able to index 100k documents without issue (under 6min?), while your full collection (~450k) encounters difficulty.

<小时/>

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

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

  2. 限制索引器以跟上集群摄取容量的步伐。

<小时/>

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

关于python - 450K 文档的 ElasticSearch 索引 - 性能,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39972655/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com