amazon-web-services - Elasticsearch渗透在AWS EC2上非常缓慢

Question

最近，我们将集群切换到EC2，一切正常……除了渗滤:(

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

一个渗滤请求(真正的渗滤请求，是从正在运行的php进程中窃取的)在负载(16个php进程中)的负载下大约占用2m20s。如果EC2上的资源之一被用完了，那没关系，但这很奇怪(请参见stats output，但也可以在htop，iotop和iostat上看到):load，cpu，memory，heap，io；一切都很好(很好)。似乎没有资源短缺，但渗滤性能很差。

当我们退出php进程并再次尝试percolate请求时，它将在15秒左右出现。只是要清楚:我对2分钟以上的多重渗滤请求没有问题。只要我知道其中一种资源已被充分利用(并且我可以通过提供更多所需资源来对其采取行动)。

所以，好吧，这不是通常的怀疑，让我们尝试其他方法:

为了排除网络，协调等问题，我们还从节点本身(使客户端启用)执行了相同的请求，同时对php进程施加了相同的压力:无需更改

我们在processors中升级了elasticsearch.yml配置，并重新启动该节点以伪装我们的方式来占用更多资源:没有变化。

我们尝试调整percolate和get池大小和队列大小:不变。

当我们查看热线程时，我们的DiscovereUsageTrackingQueryCachingPolicy出现了很多，因此我们按照this issue中的建议进行了操作:没有变化。

也许是副本的数量，看到Elasticsearch也使用这些副本进行搜索吗？我们将其提高到3，并使用更多的EC2进行分发:没有变化。

为了确定我们是否可以实际使用EC2上的所有资源，我们进行了压力测试，一切看起来都很好，使其负载超过40。IO，内存等在高压力下也没有问题。

它仍然可以是批处理大小。在负载下，我们直接在数据和客户端节点(专用于此索引)上尝试了多个percolate请求中的仅一个percolator批次，发现它使用了1m50s。当我们尝试一批200个渗滤器(仍在一个多重渗滤剂请求中)时，使用了2m02(大致与之前的15s结果相符，没有压力)。

最后一点可能很有趣! 似乎它长时间停留在某处，然后非常顺利地经历了渗滤阶段。

任何人都可以从中赚钱吗？我们错过了什么吗？如果需要，我们可以提供更多数据。

Answer 1

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

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