使用 elasticsearch 优化服务器操作：解决低磁盘水印

Question

已编辑 - 基于 @opster elasticsearch ninja 的 cmets，我编辑了原始问题，使其专注于 ES 的低磁盘水印错误。

有关小型机器上更一般的服务器优化，请参阅： Debugging Elasticsearch and tuning on small server, single node

对于原始问题的原始跟进以及与调试 ES 故障相关的注意事项，还有： https://chat.stackoverflow.com/rooms/213776/discussion-between-opster-elasticsearch-ninja-and-user305883

---

问题：我注意到elasticsearch经常失败，需要手动重启服务器。

此问题可能与：High disk watermark exceeded even when there is not much data in my index

我想更好地了解如果磁盘大小失败，elasticsearch 会做什么，如何优化配置，然后最终在系统失败时自动重启。

您能否帮助了解如何阅读 elasticsearch 日志并做出相应的选择来解决问题，并建议在小型服务器机器上调整服务器操作的最佳实践？

我的首要任务是不让系统崩溃；性能稍差一点也没关系，没有增加服务器大小的预算。

硬件

我在单个小型服务器（2GB）上运行弹性搜索，有 3 个索引（500mb、20mb 和 65mb 的存储大小）和几个 GB 的磁盘空闲（状态稳定）：我想允许使用虚拟内存 VS 消耗内存。

低于我所做的：

---

期刊怎么说？

journalctl | grep elasticsearch> 探索与 ES 相关的故障。

    May 13 05:44:15 ubuntu systemd[1]: elasticsearch.service: Main process exited, code=killed, status=9/KILL
May 13 05:44:15 ubuntu systemd[1]: elasticsearch.service: Unit entered failed state.
May 13 05:44:15 ubuntu systemd[1]: elasticsearch.service: Failed with result 'signal'.

在这里我可以看到 ES 被杀死了。

已编辑：我发现由于 java 的内存不足错误，请参阅以下 service elasticsearch status 中的错误；读者可能也会觉得运行起来很有用：

java -XX:+PrintFlagsFinal -version | grep -iE 'HeapSize|PermSize|ThreadStackSize'

检查当前的内存分配。

ES 日志是怎么说的？

检查：

/var/log/elasticsearch


[2020-05-09T14:17:48,766][WARN ][o.e.c.r.a.DiskThresholdMonitor] [my_clustername-master] high disk watermark [90%] exceeded on [Ynm6YG-MQyevaDqT2n9OeA][awesome3-master][/var/lib/elasticsearch/nodes/0] free: 1.7gb[7.6%], shards will be relocated away from this node
[2020-05-09T14:17:48,766][INFO ][o.e.c.r.a.DiskThresholdMonitor] [my_clustername-master] rerouting shards: [high disk watermark exceeded on one or more nodes]

如果我只有一台服务器和一个实例在工作，“分片将从该节点重新定位”是什么意思？

service elasticsearch status

 Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-05-09 13:47:02 UTC; 32min ago
     Docs: http://www.elastic.co
  Process: 22691 ExecStartPre=/usr/share/elasticsearch/bin/elasticsearch-systemd-pre-exec (code=exited, status=0/SUCCES
 Main PID: 22694 (java)
   CGroup: /system.slice/elasticsearch.service
           └─22694 /usr/bin/java -Xms512m -Xmx512m -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+U

我的配置说明了什么？

我正在使用 `/etc/elasticsearch/elasticsearch.yml´ 的默认配置

并且没有为水印配置任何选项，例如https://stackoverflow.com/a/52006486/305883

我应该包括它们吗？他们会怎么做？

请注意我已取消注释#bootstrap.memory_lock: true 因为我只有 2gb 的内存。

即使弹性搜索在内存交换时性能不佳，我的首要任务是它不会失败，并且网站保持正常运行。

在单节点机器上运行 - 如何处理未分配的副本？

我了解不能在同一节点上分配副本。 因此，在单个节点上拥有副本是否有意义？ 如果主索引失败，副本会来救援还是无论如何都不会被使用？

我想知道我是否应该删除它们并腾出空间，或者最好不要。

Answer 1

您的问题的解释：

如果我只有一台服务器和一个实例工作，则分片将从该节点重新定位”？

Elasticsearch 在决定之前会考虑可用磁盘空间 是否分配新的分片、重新定位分片或将所有分片 基于此错误的不同阈值的阅读模式索引， 原因是 Elasticsearch 索引由不同的分片组成 持久化在数据节点上，磁盘空间不足会导致上述情况 问题。

在您的情况下，由于您只有一个数据节点，因此同一数据节点上的所有索引都将进入读取模式，即使您释放了 空间它不会进入写作模式，直到你明确地点击 操作员指南中提到的 API。

编辑：在单个节点上最好禁用副本，因为 Elasticsearch 不会将分片的副本分配给同一数据节点。因此，在单节点 Elasticasearch 集群上拥有副本是没有意义的，这样做会不必要地将您的索引和集群健康标记为黄色（缺少副本）。