Служебное сообщение Elasticsearch gc при попытке выполнить логический запрос OR с получением всех совпадающих документов одновременно

Я использую Elasticsearch 7.6 и клиентский API PHP для всех операций. Я создал настройки и сопоставления индекса elasticsearch следующим образом

$params = [
    'index' => $index,
    'body' => [
        'settings' => [
            "number_of_shards" => 1,
            "number_of_replicas" => 0,
            "index.queries.cache.enabled" => false,
            "index.soft_deletes.enabled" => false,
            "index.refresh_interval" => -1,
            "index.requests.cache.enable" => false,
            "index.max_result_window"=> 2000000
        ],
        'mappings' => [
            '_source' => [
                "enabled" => false
             ],
             'properties' => [
                "text" => [
                        "type" => "text",
                        "index_options" => "docs"
                ]
        ]
     ]
    ]
];

Мой логический поисковый запрос OR выглядит следующим образом

$json = '{
"from" : 0, "size" : 2000000,
"query": {
       "bool": {
       "filter": {
        "match" : {
            "text" : {
            "query" : "apple orange grape banana",
            "operator" : "or"
            }
        }
    }
}
}
}';

Я проиндексировал 2 миллиона документов таким образом, что все документы соответствуют запросу, и я также получаю все документы, как и ожидалось. Поскольку я сопоставляю все документы, я избежал оценки с помощью фильтра в запросе bool.

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

[2020-05-15T19:15:45,720][INFO ][o.e.m.j.JvmGcMonitorService] [node1] [gc][14] overhead, spent [393ms] collecting in the last [1.1s]
[2020-05-15T19:15:47,822][INFO ][o.e.m.j.JvmGcMonitorService] [node1] [gc][16] overhead, spent [399ms] collecting in the last [1s]
[2020-05-15T19:15:49,827][INFO ][o.e.m.j.JvmGcMonitorService] [node1] [gc][18] overhead, spent [308ms] collecting in the last [1s]

Я выделил 16 ГБ для своей кучи памяти. Никаких других предупреждений в журнале elasticsearch не отображается. В чем может быть причина? или это ожидается при извлечении огромного количества документов ?. Я понимаю API прокрутки, но мне любопытно, почему это происходит, когда я использую большое значение для index.max_result_window. Помощь очень ценится? Заранее спасибо!


person Mohamed Abdullah    schedule 15.05.2020    source источник


Ответы (1)


Вы видите нормальное поведение Elasticsearch с указанной конфигурацией в частности и любого Java-приложения в целом.

Это нормально для ES с большим index.max_result_window?

да. Как указано в документации по index.max_result_window, количество сгенерированного мусора пропорционально количеству документов, возвращаемых запросом:

Поисковые запросы занимают память кучи и время, пропорциональное размеру from +, и это ограничивает эту память.

Применимо ли это также к массовым запросам API?

Да, если ваш массовый запрос имеет большой размер, он может вызвать сборку мусора.

Естественно, ES выделяет документы, которые необходимо отправить обратно пользователю, в куче, сразу после этого они становятся мусором и, таким образом, подлежат сборке мусора.

Как работает сборка мусора в Java?

Вы можете найти соответствующую информацию, например, здесь.

Есть ли лучший способ запросить все совпадающие документы?

Например, match_all запрос.

Чем это лучше по сравнению со всеми документами, соответствующими определенному запросу? Elasticsearch не должен запрашивать индексы и может сразу же перейти и получить документы (лучшая производительность и использование ресурсов).

Должен ли я использовать API прокрутки или текущий подход достаточно хорош?

Scroll API - это рекомендуемый способ, поскольку он масштабируется далеко за пределы объема памяти одного узла Elasticsearch (можно загрузить 1 ТБ данных из кластера из нескольких машин с примерно 16 ГБ ОЗУ).

Однако, если вы хотите по-прежнему использовать обычные поисковые запросы, вы можете рассмотреть возможность использования _ 3_ и size и выполнить разбиение на страницы (таким образом ограничивая количество документов, выбираемых по запросу, и улучшая распределение GC с течением времени).

Надеюсь это поможет!

person Nikolay Vasiliev    schedule 16.05.2020
comment
Спасибо, Николай !. Мне удалось увеличить пространство Eden в сборщике мусора JVM и избавиться от сообщения. - person Mohamed Abdullah; 17.05.2020