ElasticSearch – 高索引吞吐量

我正在对ElasticSearch进行基准testing，以获得非常高的索引吞吐量。

我目前的目标是能够在数小时内索引30亿（30亿）文件。为此，我目前有3个Windows服务器机器，每个16GB RAM和8个处理器。被插入的文档有一个非常简单的映射，只包含一些数字非分析字段（ _all被禁用）。

我能够使用这个相对适中的钻机，每秒钟可以达到大约12万个索引请求（使用大桌面进行监控），我相信吞吐量可以进一步提高。我正在使用多个.net NEST客户端发送索引批量请求，批量使用1500个索引操作。

不幸的是，每秒钟12万个请求的吞吐量不会持续很长时间，速率会逐渐下降，几个小时后就会下降到15K左右。

监测机器显示，CPU不是瓶颈。但是，物理磁盘（不是SSD）的空闲时间似乎在所有机器上都下降，平均闲置时间低于15％。

设置refresh_interval为60s，而不是300s，最后15m，似乎没有多大帮助。在单个分片中窥探单个超时日志，显示超时logging每隔30分钟刷新一次，然后达到200MB。

我曾尝试使用两个分片策略：

1个指数，有60个碎片（没有副本）。
3个指数，每个20个分片（没有副本）。

这两种尝试导致相当相似的经验，我认为是有道理的，因为它是相同数量的碎片。

从细分市场看，大多数细分市场都有约30个细分市场，同样也有相似数量的可search细分市场。分段大小各不相同。有一次，max_num_segments = 1优化索引的尝试在完成之后似乎有一点帮助（需要很长时间）。

在任何时候，从一开始就启动整个摄取过程，在删除使用过的索引并创build新的索引之后，导致相同的行为。起初高指数的吞吐量，但逐渐减less，很久之前，达到30亿文件的目标。当时的索引大小约为120GB。

我正在使用ElasticSearch 1.4版本。 Xms和Xmxconfiguration为8192MB，可用内存的50％。索引缓冲区设置为30％。

我的问题如下：

假设磁盘目前是这台钻机的瓶颈，这种磁盘利用率逐渐增加的现象是否正常呢？如果没有，可以做些什么来否定这些影响？
有没有任何微调，我可以做，以提高索引吞吐量？我是不是该？还是应该扩大规模？

长话短说，我用5台虚拟linux机器，8个CPU，16GB，用puppet部署elasticsearch。我的文件有点大，但是通过率（略）。平均每秒可以达到15万个索引请求，在2个小时内索引10亿个文件。吞吐量不是恒定的，我观察到与以前相似的递减吞吐量行为，但程度较小。由于我将使用相同数据量的每日指数，我预计这些performance指标每天大致相似。

从Windows机器到Linux的过渡主要是由于方便和符合IT约定。虽然我不确定，但我怀疑在windows上也可以达到同样的效果。

在我的几个试验中，我试图按照Christian Dahlqvist的build议，没有指定文件ID。结果是惊人的。我观察到吞吐量显着增加，在某些情况下达到30万甚至更高。这个结论是显而易见的：不要指定文件ID，除非你绝对必须。

此外，我使用每台机器更less的碎片，这也有助于提高吞吐量。