更新:当心长篇
在我变大并迁移到更大的服务器之前，我想了解这个服务器有什么问题。
这是 AWS (EC2) 中 Elasticsearch 服务器的 MVP。两个 micro-s，每个只有 600mb ram。
我想了解这个配置有什么问题。如您所见，批量命令存在瓶颈。操作系统内存已满，堆内存仍然很低，尽管进程 CPU 最大运行，但操作系统 cpu 很低。
我降低了批量提要中每个文档的复杂性，并将不需要的字段设置为不被索引。下面的截图是我最后一次尝试。
是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、磁盘、网络...)不足以甚至更好地更有效地使用现有来源。
最佳答案
您能否针对要批量索引的索引运行 IndexPerfES.sh script，然后我们可以查看性能是否有所提高。我认为刷新率会降低性能，并且可能会对集群造成压力，从而导致问题。让我知道，我们可以解决这个问题。
关于amazon-ec2 - 批量查找ES瓶颈(附bigdesk截图)，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/22802547/