При распределении памяти, необходимо выделить память для самого 019 контейнера elasticsearch memlimit, в зависимости от 020 количества выделенной памяти для контейнера, нужно добавить 021 переменную окружения ES_JAVA_OPTS, память, выделенная через данную 022 переменную, будет использована для системного кэша.
023 024Важно: память, которая выдается через 025 ES_JAVA_OPTS, не должна превышать 50% доступной ОЗУ, выделенной на 026 контейнер, потому что вся оставшаяся память будет выделена для 028 Apache Lucene.
029 030Подробнее можно прочитать 032 здесь.
033В зависимости от потребностей, можно выделить менее 50% памяти, 037 вся оставшаяся память будет выделена для Apache Lucene, что может 038 улучшить производительность. Данная практика советуется, если не 039 производятся операции, связанные с агрегированием строк 040 (fielddata).
041 042Подробнее можно прочитать 044 здесь.
045Для лучшей работы heap size для elasticsearch не должен 049 превышать 051 30GB, так как при использовании меньшей памяти, используются 053 сжатые указатели.
054 055Дополнительно можно ознакомиться 057 здесь.
058В идеале использовать не больше 4GB heap sizing, так как будут 062 использованы 32-битные 064 указатели.
065Выделяемая память для elasticsearch должна быть как можно 069 меньше, не рекомендуется выделять много памяти, так как это может 070 привести к более долгим паузам сборщика 072 мусора.
073При выделении малого количества памяти сборщик мусора не будет 077 освобождать ресурсы в достаточном количестве, что приведет к переполнению 079 памяти. Также при выполнении запросов, если сервер ноды 080 кластета elasticsearch достигает состояния, при котором происходит 081 нехватка ресурсов, сервер может перестать отвечать, 083 во избежание полного отключения.
084Нормальное состояние работы сборщика мусора заключается в частых 093 и периодических срабатываниях освобождения ресурсов в достаточном 094 количестве. Используемая память при работе elasticsearch 095 варьируется от 30% до 70% от общей доступной памяти, выделенной на 096 JAVA процесс ноды, находящейся в кластере elasticsearch, 098 при нормальном состоянии.
099Нагрузка на память не должна превышать в стабильном состоянии 103 75%. При высокой потребности нагрузка не должна превышать 105 85%.
106При нагрузке выше чем 111 85% стоит провести мониторинг работы сервера elasticsearch, так 112 как это может привести к дальнейшим 114 проблемам.
115 116Возможные решения можно просмотреть 118 здесь.
119 120Заметка: чтобы проверить нагрузку на ноды, 121 можно сделать следующий запрос
122 123
124 GET {host}/_cat/nodes?v&h=name,node*,heap*
125
126
127
128 где host - это хост ноды elasticsearch.
129При работе состояние кластера должно иметь статус 138 Green, это означает, что для каждого основного шарда, 139 количество созданных репликационных шардов соответствует настройке 140 количества репликационных шардов для всех индексов. В ином случае 141 статус будет 143 желтый или красный.
144Количество создаваемых реплик не должно быть больше или равно 148 количеству нод в кластере elasticsearch, так как репликационный 149 шард не может создаваться на той же ноде, на которой присутствует 150 основной шард. Подробнее можно прочитать 152 здесь или 154 здесь.
155Настройку количества репликационных шардов можно проверить в 159 настройках индекса по пути:
160 161
162 index.number_of_replicas
163
164
165 Количество шардов на каждой ноде может быть неограниченным, но 174 для лучшей производительности, на 1GB памяти JVM, иметь не более 176 20 шардов.
177Также рекомендуется иметь шарды размером от 182 20GB до 40GB. Иметь шарды меньшего размера не 184 оптимально.
185Также стоит настроить 190 ILM для решения проблемы с большим количеством 192 шардов.
193