AWS EC2上的弹性搜索渗透速度很慢

Question

最近我们将我们的集群切换到EC2，一切都很好......除了渗透:(

我们使用Elasticsearch 2.2.0。 要重新索引（和渗透）我们的数据，我们使用单独的EC2 c3.8xlarge实例（32核，60GB，2 x 160 GB SSD）并告诉我们的索引仅包括此节点的分配。 因为我们稍后会在其余节点之间分发它，所以我们使用10个分片，没有副本（仅用于索引和渗透）。 索引中有大约2200万份文件和15.000个过滤器。该索引小于11GB（因此很容易适应内存）。 大约16个php进程与REST API进行通信，执行多个percolate请求，每个请求200个请求（由于性能的原因，我们将其设置为较小，之前每个请求为1000个）。

一个渗透请求（真正的一个，从运行的php进程中取出）在负载下（大约16个php进程）需要大约2分20秒。如果EC2上的其中一个资源被最大化，那就没问题了，但这很奇怪（在这里看stats output但在htop，iotop和iostat上也看到了）：load，cpu ，记忆，堆，io;一切都很好（非常好）在限度内。似乎没有资源短缺，但渗透性能仍然不好。

当我们退出php进程并再次尝试percolate请求时，它会在15秒左右出现。需要明确的是：我没有遇到2分钟+多次渗透请求的问题。只要我知道其中一个资源得到充分利用（我可以通过给予它更多的东西来对其采取行动）。

所以，好吧，这不是通常的嫌疑人，让我们试试不同的东西：

• 为了排除网络，协调等问题，我们也从节点本身（启用客户端）执行了与php进程相同压力的相同请求：无变化
• 我们在processors中增加了elasticsearch.yml配置并重新启动了节点以伪装成更高的资源使用率：无变化。
• 我们尝试调整percolate和get池大小和队列大小：没有变化。
• 当我们查看热线时，我们DiscovereUsageTrackingQueryCachingPolicy出现了很多，所以我们按照this issue中的建议做了：没有变化。
• 也许它是副本的数量，看到Elasticsearch也使用它们进行搜索？我们将它增加到3并使用更多的EC2来展开它们：没有变化。
• 为了确定我们是否可以实际使用EC2上的所有资源，我们进行了压力测试，一切看起来都很好，将其加载到40以上。此外，IO，内存等在高应变下没有显示任何问题。
• 它可能仍然是批量大小。在负载下，我们在多次渗透请求中尝试了一批只有一个过滤器，直接在数据和数据上。客户端节点（专用于此索引），发现它使用1m50s。当我们尝试一批200个过滤器（仍然在一个多渗透要求中）时，它使用了2m02s（大致与早期的15s结果相符，没有压力）。

这最后一点可能很有意思！似乎它在某个地方停留了很长时间，然后非常顺利地完成了渗透阶段。

任何人都能做出任何改变吗？我们错过了什么？如果需要，我们可以提供更多数据。

Answer 1

请查看the thread on the Elastic Discuss forum以查看解决方案。

TLDR; 在一台大型服务器上使用多个节点以获得更好的资源利用率。