performance - 使用Elasticsearch优化服务器操作:解决磁盘空间不足的问题

Question

编辑-基于@opster elasticsearch ninja的评论，我编辑了原始问题，以使其专注于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)上运行elasticsearch，具有3个索引(存储大小分别为500mb，20mb和65mb)和几个GB的可用磁盘空间(固态):我想允许使用虚拟内存VS消耗RAM。

下面是我做的:

该日记怎么说？
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的RAM。

即使在交换内存时Elasticsearch的性能不佳，我的首要任务是它也不会失败，并且站点可以正常运行。

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

我知道不能在同一节点上分配副本。
结果，在单个节点上具有副本是否有意义？
如果主索引将失败，副本将可以挽救，或者它们仍将不被使用？

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

Answer 1

请阅读detailed explanation of opster's指南，了解什么是低磁盘水印以及如何临时固定修复它。

您的问题的解释:

如果我只有一台服务器和一个实例在工作，碎片将被移离该节点。

Elasticsearch considers the available disk space before deciding whether to allocate new shards, relocate shards away or put all indices on reading mode based on a different threshold of this error, Reason being Elasticsearch indices consists of different shards which are persisted on data nodes and low disk space can cause the above issues.

In your case, as you have just one data node, all the indices on the same data node will be put into reading mode and even if you free up space it wouldn't come in writing mode until you explicitly hit the API mentioned in opster's guide.

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