оптимизировать работу сервера с помощью elasticsearch: устранение водяных знаков низкого уровня на диске - PullRequest
Новая
       106

оптимизировать работу сервера с помощью elasticsearch: устранение водяных знаков низкого уровня на диске

1 голос
/ 09 мая 2020

EDITED - Основываясь на комментариях @opster elasticsearch ninja, я отредактировал исходный вопрос, чтобы сосредоточить внимание на ошибке водяных знаков низкого диска для ES.

Для более общей оптимизации сервера на небольшой машине см .: Отладка Elasticsearch и настройка на небольшом сервере, одиночный узел

Для первоначального ответа на исходный вопрос и связанных соображений для отладки сбоев ES, а также: https://chat.stackoverflow.com/rooms/213776/discussion-between-opster-elasticsearch-ninja-and-user305883

Проблема : Я заметил, что elasticsearch часто дает сбой и необходимо перезапустить сервер вручную.

Этот вопрос может относиться к: Превышен высокий водяной знак на диске, даже если в моем индексе мало данных

Я хочу лучше понять, что сделает elasticsearch, если размер диска не работает, как оптимизировать конфигурацию и только потом, в конечном итоге, автоматически перезагружается при сбое системы.

Не могли бы вы помочь в понимании того, как читать журнал elasticsearch и сделать выбор, чтобы исправить проблемы соответствующим образом, предлагая передовые методы настройки работы сервера на небольшом сервере?

Мой приоритет не иметь сбой системы; нормально иметь немного меньшую производительность, нет бюджета на увеличение размера сервера.

Аппаратное обеспечение

Я запускаю elasticsearch на одном небольшом сервере (2 ГБ), имею 3 (500 МБ, 20 МБ и 65 МБ размера хранилища) и несколько ГБ свободного места на диске (состояние solid): я хотел бы разрешить использование виртуальной памяти 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 был убит.

EDITED : я обнаружил из-за ошибки нехватки памяти из 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, потому что у меня только 2 ГБ оперативной памяти.

Даже если elasticsearch будет плохо работать при подкачке памяти, мой приоритет - это

Работа на машине с одним узлом - как обрабатывать неназначенные реплики?

Я понял, что реплики нельзя назначать на те же узлы. Как следствие, имеет ли смысл иметь реплики на одном узле? Если первичный индекс выйдет из строя, на помощь придут реплики, или они все равно не будут использоваться?

Интересно, следует ли мне удалить их и освободить место, или лучше не делать этого.

1 Ответ

1 голос
/ 10 мая 2020

Пожалуйста, прочтите подробное объяснение руководства opster о том, что такое низкий водяной знак на диске, и как временно и постоянно исправлять его.

Объяснение вашего вопроса:

Осколки будут перемещены из этого узла «, если у меня работает только один сервер и один экземпляр?

Elasticsearch рассматривает доступное дисковое пространство, прежде чем решить, следует ли выделять новые фрагменты, перемещать фрагменты или перевести все индексы в режим чтения на основе другого порога этой ошибки. Причина в том, что индексы Elasticsearch состоят из разных сегментов, которые сохраняются на узлах данных, и нехватка места на диске может вызвать вышеуказанные проблемы.

В вашем случае, поскольку у вас есть только один узел данных, все индексы на одном узле данных будут переведены в режим чтения , и даже если вы освободите место, оно не перейдет в режим записи, пока вы явно не нажмете API упоминается в руководстве оператора.

Изменить: На одном узле было бы лучше чтобы отключить реплику, так как Elasticsearch не будет выделять реплику осколка на тот же узел данных . Поэтому нет смысла иметь реплики в кластере Elasticasearch с одним узлом, и это приведет к тому, что ваш индекс и состояние кластера будут помечены желтым цветом (отсутствует реплика).

...