我在将文档索引到ElasticSearch时被阻止了。我试图将（仅）〜3.7M文档索引到ES索引中，＆amp;索引~3.4M文档（占用大约3GB磁盘空间）后，索引速率降至约10 docs / min，这非常令人担忧。
索引（错误地）只有一个碎片，我认为这可能会导致某个地方出现瓶颈。
Elasticsearch版本：1.7.1
节点配置：
m3.large（7.5 GB RAM，32 GB SSD存储）
ES_Heap_size：1 GB（这是我在KOPF上看到的，它也显示堆使用情况：约100MB的~400MB）
每个节点附带50GB EBS卷
我们正在使用TransportClient与ES进行交互。 BulkProcessor已配置为5 MB的批量大小，2分钟的刷新间隔（以避免发送数据<5 MB，我们是批量索引）＆amp; 6个并发请求。 ES可以有大约10个批量请求。
在看到索引速度减慢后，我做了以下事情：
＆gt;将群集设置更改为2＆amp;的threadpool.bulk.size。 threadpool.bulk.queue_size：80。
＆gt;关闭我的索引的索引刷新。
＆gt;将number_of_replicas设置为0（之前为1）。
＆gt; indices.store.throttle.type也被设置为“none”，以避免在段合并时索引限制。
以上都没有帮助。
KOPF仪表板显示大约<14％的CPU使用率。
请帮忙。谢谢！
答案 0 :(得分：2)
我曾使用Bulkprocessor并插入大约7密耳（150秒）的记录，但在ES方面的任何一点都没有观察到缓慢。 我使用了使用传输客户端在Java中实现的BulkProcessor（单线程）。其余的配置几乎相同。
如果上面的结果看起来很有意义，那么也许你可以尝试一些事情：
检查程序代码的运行时内存使用情况（正在读取/处理/写入的位置）。它可能触及最大可用内存。在Java的情况下，检查程序可用的已分配的Java堆。
尝试使用多节点配置（我在单个窗口上使用三个节点ES群集m / c）
答案 1 :(得分：1)
你的日志中是否有“RejectionException”？这表明队列正在填满，索引无法跟上。服务器上打开文件/连接的数量怎么样？可能值得检查用户＆amp;全球限制。 关于更改threadpool.bulk.size设置。这是一个坏主意，因为默认值大多是准确的，并根据您机器上的核心数设置。 尝试使用批量大小来查看它是否设置完好。
答案 2 :(得分：0)
这是一个猜测，但是如果您直接使用bulkRequest.get()而没有BulkProcessor - 它不是设计用于循环。一些内部清理没有发生，并且客户端（！）方面的性能呈指数级恶化。有关示例，请参阅this link。