Размер кучи - это объем оперативной памяти, выделяемый виртуальной машине Java узла OpenSearch.
Как правило, для параметров -Xms и -Xmx следует устанавливать одинаковое значение, которое должно составлять 50% от общего объема доступной оперативной памяти, но не более (примерно) 31 ГБ.
Больший размер кучи позволит узлу получить больше памяти для операций индексирования и поиска. Однако узлу также требуется память для кэширования, поэтому использование 50% позволяет поддерживать здоровый баланс между этими двумя параметрами. По этой же причине в производстве следует избегать использования других процессов с большим объемом памяти на одном узле с OpenSearch.
Использование кучи обычно происходит по схеме "зубья пилы", колеблясь между 30 и 70% от максимально используемой кучи. Это происходит потому, что JVM постоянно увеличивает процент использования кучи, пока процесс сборки мусора снова не освободит память. Высокий уровень использования кучи возникает, когда процесс сборки мусора не успевает за ним. Индикатором высокого использования кучи является ситуация, когда сборка мусора не в состоянии уменьшить использование кучи примерно до 30%.
На приведенном выше рисунке вы можете видеть нормальную пилообразную форму кучи JVM.
Вы также видите, что существует два типа сборки мусора - молодая и старая GC.
В здоровой JVM сборка мусора в идеале должна удовлетворять следующим условиям:
- Young GC выполняется быстро (в течение 50 мс).
- Young GC выполняется нечасто (около 10 секунд).
- Old GC обрабатывается быстро (в течение 1 секунды).
- Old GC выполняется нечасто (раз в 10 минут или чаще).
Как решить проблему, когда использование кучной памяти слишком велико или когда производительность JVM не оптимальна
Увеличение использования кучи памяти может происходить по разным причинам:
Большие размеры агрегации
Чтобы избежать больших размеров агрегации, сведите количество агрегатных бакетов (размер) в запросах к минимуму.
1 2 3 4 5 6 7 8 9 10 11 | GET /_search { "aggs" : { "products" : { "terms" : { "field" : "product", "size" : 5 } } } } |
Вы можете использовать медленную регистрацию запросов (slow logs) и реализовать ее на конкретном индексе с помощью следующих действий.
1 2 3 4 5 6 7 8 9 10 11 12 | PUT /my_index/_settings { "index.search.slowlog.threshold.query.warn": "10s", "index.search.slowlog.threshold.query.info": "5s", "index.search.slowlog.threshold.query.debug": "2s", "index.search.slowlog.threshold.query.trace": "500ms", "index.search.slowlog.threshold.fetch.warn": "1s", "index.search.slowlog.threshold.fetch.info": "800ms", "index.search.slowlog.threshold.fetch.debug": "500ms", "index.search.slowlog.threshold.fetch.trace": "200ms", "index.search.slowlog.level": "info" } |
Запросы, которые требуют длительного времени для получения результатов, скорее всего, являются ресурсоемкими.
Чрезмерный размер массового индекса
Если вы посылаете большие запросы, то это может быть причиной высокого потребления кучи. Попробуйте уменьшить размер массовых индексных запросов.
Проблемы с маппингом
В частности, если вы используете "fielddata: true", то это может быть основным потребителем кучи JVM.
Неверно установленный размер кучи
Размер кучи определяется:
Установкой переменной окружения:
1 | ES_JAVA_OPTS="-Xms2g -Xmx2g". |
Редактирования файла jvm.options в каталоге конфигурации OpenSearch:
1 2 | -Xms2g -Xmx2g |
Настройка переменной окружения имеет приоритет над настройкой файла.
Для того чтобы настройка была учтена, необходимо перезапустить узел.
Неверно задан новый коэффициент JVM
Задавать его, как правило, НЕ требуется, поскольку OpenSearch устанавливает это значение по умолчанию. Этот параметр определяет соотношение пространства, доступного для объектов "нового поколения" и "старого поколения" в JVM.
Если вы видите, что старое GC становится очень частым, можно попробовать специально задать это значение в файле jvm.options в каталоге конфигурации OpenSearch.
1 | -XX:NewRatio=3 |