Fielddata там, где ее быть не должно

(Михаил) #1

У меня есть индекс (данные в него не индексируются, только поиск по нему осуществляется по средствам кибаны и ее дашбоардов) у которого постоянно растет размер fielddata. Стал разбираться и обнаружил с помощью запроса GET /_cat/fielddata?v&s=size что филддата растет для поля request_uri.keyword.
На сколько я понял из документации

  1. филддата по умолчанию выключена (а сам я ее не включал)
  2. филддата не может быть для keyword полей.

Так же путем практических тестов стало понятно что филддата растет из-за того что делаешь сортировку в табличном виджете содержащем поле request_uri.keyword
Филддата растет и никогда сама не сбрасывается. Сбросить ее можно только либо рестартанув кластер, либо отправив запрос POST /<index_name>/_cache/clear?fielddata=true

Кроме того, обнаружил что другой аналогичный индекс, но в который идет непрерывная индексация - филддату тоже имеет, но она постоянно сбрасывается (это видно на графике):

image
image.png870×239 49.5 KB

Вопросы:

  1. Какова природа филддаты в моем случае?
  2. Как мне избавится от филддаты?
(Igor Motov) #2

Какая версия elasticsearch и как выглядит маппинг для request_uri в индексе, где филддата растет?

(Михаил) #3

эластик 6.5.2
Мапинг вот такой:

      "request_uri" : {
        "type" : "text",
         "fields" : {
          "keyword" : {
            "type" : "keyword",
            "ignore_above" : 256
          }
        }
      }

Пробовал вот так:

      "request_uri" : {
        "type" : "text",
        "fielddata" : "false",
        "fields" : {
          "keyword" : {
            "type" : "keyword",
            "ignore_above" : 256
          }
        }
      }

После чего сделал reindex, но филддата все равно появляется.

(Igor Motov) #4

Это выключает fielddata для request_uri, а не для request_uri.keyword. Но на самом деле это не важно. Все равно там fielddata быть не должно. То, что вы видите в stats это на самом деле не fielddata, а global ordinals (часть docvalues, которая храниться в памяти) расти они немного могут, но много места они занимать не должны.

(Михаил) #5

Я понимаю это, но при попытке прописать эту опцию для request_uri.keyword эластик выдает ошибку.

Как можно убедиться что это именно global ordinals, а не fielddata? Текущий способ проверки о котором я писал выше завел меня в заблуждение (и не только меня, мои коллеги из другой организации попались на ту же удочку)

Ок. Немного это сколько? Немного в рамках одного индеса или как? В моем кластере памяти на это уходит довольно много и как я уже сказал выше, если в индекс идет непрерывная индексация то объем занимаемой памяти действительно не так велик и он очищается периодически. А если говорить об индексах по которым осуществляется только поиск (индексации нет), объем занимаемой памяти только растет и растет и помогает либо рестарт ноды, либо POST /<index_name>/_cache/clear?fielddata=true (опять же таки судя по этому запросу должна происходить очистка именно fielddata, а не global ordinals). В противном случае если не произвести очистку то со временем нода падает по памяти.

(Igor Motov) #6

По умолчанию, размер памяти по fielddata ограничин 30%. Так что у вас там где-то еще что-то убегает. На стаистику надо посмотреть, перед самым падением.

(Михаил) #7

По умолчанию, размер памяти по fielddata ограничин 30%. Так что у вас там где-то еще что-то убегает.

Ну у меня хип сайз 32Гб , без филддаты (если ее очистить принудительно) хип сайз забит как раз процентов на 70%, когда филддата достигает своих 30% класетр падает. Так что ничего не утекает больше. А если филддату чистить раз в сутки например то кластер и вовсе не упадет.

Игорь, могли бы вы ответить на мои вопросы из прошлого сообщения? Я так и не пойму с чем же я все таки имею дело с fielddata или же с global ordinals...

(Igor Motov) #8

Скорее всего, вы имеете дело с global ordinals которые в статистике подходят под категорией fielddata.

(Михаил) #9

Можете подсказать как бороться с проблемой?

(Igor Motov) #10

Можете подсказать как бороться с проблемой?

Добавить больше нод. 70% это слишком много.

Можно еще попробовать убавить indices.fielddata.cache.size