批量查找ES瓶颈（附带bigdesk屏幕截图）

Question

更新：谨防长篇

在我走向更大的服务器之前，我想了解这个问题的原因。

这是AWS（EC2）中的elasticsearch服务器的MVP。两个micro-s，每个只有600mb ram。

我想了解这种配置有什么问题。正如您所看到的那样，批量命令存在瓶颈。操作系统内存已满，堆内存仍然很低，虽然进程CPU运行的最大值，但OS cpu很低。

我降低了批量Feed中每个文档的复杂性，并将不需要的字段设置为不编入索引。下面的截图是我的最后一次尝试。

这是一个I / O瓶颈吗？我将数据存储在S3存储桶中。

服务器信息：

2个节点（每个服务器一个），3个索引，每个节点运行2个分片和1个副本。所以它是一个运行备份的主节点。奇怪的是“钢铁侠”节点从未接管过碎片。

我再次运行具有上述群集状态的馈线，并且瓶颈似乎在两个节点上：

以下是送纸器的开头：

主要：

辅助（辅助有瓶颈）：

---

喂食5分钟后：

主要（现在主要有瓶颈）

次要（次要现在更好）：

---

我正在使用py-elasticsearch，因此请求会在流媒体中自动限制。然而，在下面的大瓶颈之后它抛出了这个错误：

elasticsearch.exceptions.ConnectionError: 
ConnectionError(HTTPConnectionPool(host='IP_HERE', port=9200): 
Read timed out. (read timeout=10)) caused by: 
ReadTimeoutError(HTTPConnectionPool(host='IP_HERE', port=9200): 
Read timed out. (read timeout=10))

以下是关于同一“批量投放”的非常有趣的截图。队列达到20，python抛出上面的表达式，refresh命令运行到现在我正在写。

---

我的目标是了解哪些来源（CPU，RAM，磁盘，网络......）不足以甚至更好地更有效地使用现有资源。

Answer 1

所以Nate的脚本（以及其他）减少了刷新间隔。我还要补充一些其他的发现：

刷新率正在给群集带来压力，但我继续搜索并发现了更多错误＆＃34;。一个问题是我有一个被弃用的S3.Gateway。 S3持续但比EC2音量慢。

我不仅将S3作为数据存储而且在不同的区域（ec2弗吉尼亚 - > s3 oregon）。所以通过网络发送文件。我得到了这个，因为一些旧的教程将S3作为云数据存储选项。

解决之后，＆＃34;文件被删除＆＃34;下面更好。当我使用S3时，它就像30％。这是来自Elasticsearch HQ插件。

从现在开始我们已经优化了I / O.让我们看看我们还能做些什么。

我发现CPU是个问题。虽然大办公桌说工作量很小，t1.micros是not to used for persistent CPU usage。这意味着虽然在图表CPU上没有完全使用它，因为亚马逊会间隔地限制它，实际上它们已被充分利用。

如果你放一个更复杂的大文件，它会给服务器带来压力。

快乐的开发。

Answer 2

您是否可以针对批量索引的索引运行IndexPerfES.sh script，然后我们可以查看性能是否有所改善。我认为刷新率会降低性能并且可能会对集群造成压力，从而导致出现问题。让我知道，我们可以解决这个问题。