当前位置: 首页 > 面试题库 >

使用Elasticsearch优化服务器操作:解决磁盘低水位问题

孙岳
2023-03-14
问题内容

编辑 -根据@opster elasticsearch ninja的评论,我编辑了原始问题,以使其专注于ES的低磁盘水印错误。

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

该问题可能与以下内容有关:即使索引中没有太多数据,也超出了磁盘高水位标记
我想更好地了解如果磁盘大小失败,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´的默认配置

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

请注意,我没有评论,#bootstrap.memory_lock: true 因为我只有2GB的RAM。

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

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

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

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


问题答案:

请阅读关于什么是低磁盘水印以及如何临时永久性修复的Opster指南的详细说明。

您的问题的解释:

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

Elasticsearch在根据此错误的不同阈值决定是否分配新分片,重新放置分片或将所有索引置于读取模式之前,先考虑可用磁盘空间,原因是Elasticsearch索引由不同的分片组成,这些分片会持久存储在数据节点和低磁盘上空间会导致上述问题。

在您的情况下,由于您只有一个数据节点,因此同一数据节点上的所有索引都将进入读取模式
,即使您释放空间,它也不会进入写入模式,除非您明确命中opster的API中提到的API。指南。

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



 类似资料:
  • 问题内容: 我在开发机(单个笔记本)中使用Elasticsearch 1.4.4。一切都设置为默认设置,因为我从未更改任何设置。 启动它时,通常会收到以下消息: 我看到很多这样的“磁盘低水印…超出…”消息。我的情况出了什么问题?如何解决?谢谢! 更新 在这篇文章之前,我在SO中搜索了相关的文章。我发现一个与“高水印…”有关的情况,在这种情况下,磁盘空间不足。就我而言,我检查 了磁盘上是否还有56G

  • 我在我的开发机器(一个笔记本)中使用Elasticsearch 1.4.4。一切都设置为默认值,因为我从未更改任何设置。 当我启动它时,通常会收到以下信息: 我看到很多这样的“低磁盘水印…超过了…”信息。我的案子出了什么问题?如何修复它?谢谢 使现代化 在这篇文章之前,我搜索了相关的帖子。我发现了一个与“高水位线”有关的在这种情况下,磁盘空间很小。在我的情况下,我检查了一下,我的磁盘上还剩下56G

  • 本文向大家介绍关于Linux服务器磁盘空间占满问题的解决方法,包括了关于Linux服务器磁盘空间占满问题的解决方法的使用技巧和注意事项,需要的朋友参考一下 下面我们一起来看一篇关于Linux服务器磁盘占满问题解决(/dev/sda3 满了),希望碰到此类问题的人能带来帮助。 今天下班某电商技术部leader发现个问题,说他们服务器硬盘满了。把日志文件都删掉了,可硬盘空间依旧满。于是df -h查看了

  • 本文向大家介绍OpenStack Ceilometer用MongoDB解决占用磁盘空间过大问题,包括了OpenStack Ceilometer用MongoDB解决占用磁盘空间过大问题的使用技巧和注意事项,需要的朋友参考一下 OpenStack Ceilometer用MongoDB解决占用磁盘空间过大问题 背景:Ceilometer使用MongoDB作为数据库,不断进行采样,导致数据量膨胀,占用过多

  • 本文向大家介绍解决PostgreSQL日志信息占用磁盘过大的问题,包括了解决PostgreSQL日志信息占用磁盘过大的问题的使用技巧和注意事项,需要的朋友参考一下 当PostgreSQL启用日志时,若postgresql.conf日志的相关参数还使用默认值的话磁盘很容易被撑爆.因此在启用了logging_collector参数时,需要对其它相关的参数进行调整. 系统默认参数如下 调整后的参数 重点

  • 磁盘调度 磁盘访问延迟 = 队列时间 + 控制器时间 + 寻道时间 + 旋转时间 + 传输时间 磁盘调度的目的是减小延迟,其中前两项可以忽略,寻道时间是主要矛盾。 磁盘调度算法 FCFS:先进先出的调度策略,这个策略具有公平的优点,因为每个请求都会得到处理,并且是按照接收到的顺序进行处理。 SSTF(Shortest-seek-time First 最短寻道时间优先):选择使磁头从当前位置开始移动