Tag: 吞吐量

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