我有一台 32 核、62 GB RAM 的服务器，但我们有 NFS 存储，我认为它开始成为我们日常工作的瓶颈。在我们的 Kibana 中，像 queue_size 这样的错误出现得更频繁。我们刚得到一台新的(相同的)服务器，将其用作副本并分担负载，这会有帮助吗？你还有什么建议？我们有多个仪表板，每个仪表板有大约 20 个不同的变量，它们会均匀分布在主节点和副本之间吗？不幸的是，本地存储不是一种选择。
最佳答案
您是否正在积极地为这些节点上的数据编制索引？如果是，你可以增加 refresh_interval
PUT /myindex/_settings
{
"index" : {
"refresh_interval" : "30s"
}
}
https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html降低系统对IO的要求。您可以完全禁用刷新功能并手动触发它。
PUT /myindex/_settings
{
"index" : {
"refresh_interval" : "-1"
}
}
POST /myindex/_refresh
看看Bulk API它显着降低了索引阶段的负载。
向集群添加新服务器也有帮助。 Elasticsearch 旨在水平扩展。根据我的经验，您可以在您描述的服务器上运行 6-8 个虚拟节点。放置更多分片以均匀分配负载。
你知道你的瓶颈是什么吗(Lan，IO，CPU)？
关于将 NFS 存储用于 Elasticsearch 时的性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49435653/