Indexing Elasticsearch批量索引速度减慢

我无法将文档索引到ElasticSearch。我正在尝试（仅）将约370万个文档索引到ES索引中，在索引了约340万个文档（占用大约3GB的磁盘空间）后，索引率已降至约10个文档/分钟，这非常令人担忧

索引（错误地）只有一个碎片，我认为这可能会在某个地方造成瓶颈

Elasticsearch版本：1.7.1

节点配置：

m3.5大容量（7.5 GB RAM，32 GB SSD存储）
ES_Heap_size:1GB（这是我在KOPF上看到的，它还显示了堆的使用量：~1008MB中的~400MB） 与每个节点连接的50GB EBS卷

我们正在使用TransportClient与ES进行交互。已将BulkProcessor配置为5 MB的大容量，刷新间隔为2分钟（为避免发送数据），已将群集设置更改为threadpool.bulk.size of 2&threadpool.bulk.queue_size:80。
关闭我的索引的索引刷新。
将复制副本的数量设置为0（之前为1）。
index.store.throttle.type也被设置为“无”，以避免在段合并时索引限制

以上这些都没有帮助

---

KOPF仪表板显示，大约我使用了Bulkprocessor并插入了大约7 mil（150秒）的记录，但在ES侧的任何点上都没有观察到慢度。 我使用了使用传输客户端在Java中实现的BulkProcessor（单线程）

如果上述结果似乎是有希望的，那么也许您可以尝试以下几点：

检查程序代码的运行时内存使用情况（您正在读取/处理/写入的位置）。它可能会触及最大可用内存。对于Java，请检查分配给程序的Java堆

尝试使用多节点配置（我在单个windows m/c上使用了三节点ES群集）

尝试使用多个碎片。（我使用了5个碎片）

尝试将ES堆大小增加到1.5 GB左右

您的日志中是否有任何“RejectionException”？这表示队列已满，索引无法跟上。服务器上打开的文件/连接数如何？可能值得检查用户和全局限制。 关于更改threadpool.bulk.size设置。这往往是一个坏主意，因为默认值大多是准确的，并且是根据计算机上的内核数设置的。

---

试着玩弄大容量大小，看看它是否设置得很完美。

这是一个猜测，但是如果您直接使用

bulkRequest.get（）

，而不使用大容量处理器-它不是设计用于循环中的。一些内部清理没有发生，客户端（！）的性能会呈指数级下降。有关示例，请参阅