В версии 8.x данное руководство более не применимо в связи с изменением требований Elasticsearch к объему памяти на каждый шард. Накладные расходы на один шард были значительно снижены.
В старых версиях Elasticsearch действовало эмпирическое правило, согласно которому для определенного количества шардов на диске требуется минимальное количество памяти. Точное количество шардов на 1 ГБ памяти зависит от конкретного случая использования, при этом оптимальной практикой является 1 ГБ памяти на каждые 20 шардов на диске.
Справочная информация
Elasticsearch требует, чтобы каждый узел хранил в памяти имена и местоположение всех шардов кластера, а также все индексные отображения (то, что в совокупности называется "состоянием кластера"). Если состояние кластера велико, то оно требует значительного объема памяти.
Если отношение объема памяти к количеству шардов в кластере невелико, это говорит о том, что памяти недостаточно по сравнению с объемом шардов в кластере, и, следовательно, возможна нестабильность кластера. Кроме того, узлы данных должны содержать в памяти определенные структуры данных для каждого шарда, находящегося на диске. Слишком большое количество шардов на диске негативно скажется на работе узла из-за ограниченности памяти и риска возникновения проблем с производительностью и ошибок out_of_memory.
С другой стороны, если отношение объема памяти к количеству шардов велико, это означает, что узлы данных имеют больше памяти, чем требуется для того количества шардов, которое они содержат, и это может стать поводом для снижения затрат на оборудование.
Что делать при низком соотношении памяти и хранилищ
Существует несколько шагов, которые можно предпринять, чтобы исправить соотношение между памятью и осколками.
Удалить ненужные индексы
Удалить ненужные индексы можно с помощью команды:
| 1 | DELETE my-index |
По возможности закрывайте редко используемые индексы.
Приведенная ниже команда приведет к тому, что индекс больше не будет доступен для поиска, и освободит почти всю память, связанную с поддержанием индекса в кластерном состоянии. Ее можно легко отменить, выполнив команду _open.
| 1 2 | DELETE my-index POST my-index/_close |
Сокращайте индексы там, где это возможно
Можно выполнить операцию сжатия индексов, чтобы уменьшить количество шардов.
Это возможно только в том случае, если:
- Результирующий размер шардов будет меньше 50 Гб
- В индекс больше не производится запись.
Для этого также необходимо убедиться, что все шарды индекса находятся на одном узле, а для экономии ресурсов рекомендуется удалять реплики во время операции shrink.
Для этого используются следующие команды:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | PUT /my-index/_settings { "settings": { "index.number_of_replicas": 0, "index.routing.allocation.require._name": "node_name", "index.blocks.write": true } } POST /my-index/_shrink/my-shrinked-index { "settings": { "index.routing.allocation.require._name": null, "index.blocks.write": null } } |
Объединение мелких индексов в более крупные индексы
В общем случае это гораздо проще, если рассматриваемые индексы не подвергаются активному обновлению или записи. Этот процесс требует переиндексации.
Например, вот как можно переиндексировать дневные индексы в месячные для марта 2023 года:
| 1 2 3 4 5 6 7 8 9 | POST _reindex { "source": { "index": "my-index-2023-03-*" }, "dest": { "index": "reindexed-2023-03" } } |
После завершения операции (и проверки правильности копирования всех записей) можно добавить псевдоним к индексу, чтобы приложения могли продолжать читать данные, как если бы они находились в исходном индексе, и удалить старый индекс.
| 1 2 3 4 5 6 7 8 9 10 11 | POST _aliases { "actions": [ { "add": { "index": "reindexed-2022-03", "alias": "my-index-2022-03" } } ] } |
Увеличение памяти на узле
Вы можете увеличить объем оперативной памяти узла, но при этом следует помнить, что память JVM не может превышать 26 Гбайт (в некоторых случаях до 30 Гбайт) и продолжать использовать сжатые обычные указатели объектов. Примечание: JVM должна занимать не менее 50% от общего объема оперативной памяти, поэтому при увеличении памяти необходимо убедиться, что для кэша операционной системы остается не менее 50%.
Добавить в кластер новые узлы данных
Это позволит уменьшить количество шардов на узел и снизить соотношение шардов к памяти до приемлемого уровня.
Что делать, если отношение объема памяти к количеству шардов велико
Если отношение количества памяти к количеству шардов в кластере велико, это может быть признаком того, что можно сократить ресурсы узла. На производительность Elasticsearch это не окажет негативного влияния, поскольку узел имеет больше памяти, чем ему требуется на самом деле, однако это возможность сократить ресурсы и затраты.
Можно следовать лучшей практике, согласно которой на каждые 20 шардов на диске узел должен иметь 1 Гбайт памяти.
Рекомендации:
- Рассмотрите возможность сокращения числа узлов данных.
- Перейти на типы экземпляров с меньшим объемом памяти
- Уменьшить объем памяти JVM, оставив больше свободной памяти для кэша операционной системы.