Elasticsearch segments count, heap usage, and query performance

короче elasticsearch 1.4.2 но возможно пригодится для любого.

Бля ну вообщем пост должен быть был бы если бы...
Короче о другом...
curl -XGET 'http://localhost:9200/_nodes/stats/indices/segments?human&pretty' {
  "cluster_name" : "test",
  "nodes" : {
    "8Pq7sp65RteplAbVTeat8g" : {
      "timestamp" : 1463136778214,
      "name" : "test1",
      "transport_address" : "inet[/123123:9313]",
      "host" : "test1",
      "ip" : [ "inet[/sdfsdf:9313]", "NONE" ],
      "indices" : {
        "segments" : {
          "count" : 699,
          "memory" : "4.5gb",
          "memory_in_bytes" : 4902715254,
          "index_writer_memory" : "0b",
          "index_writer_memory_in_bytes" : 0,
          "index_writer_max_memory" : "815.8mb",
          "index_writer_max_memory_in_bytes" : 855506844,
          "version_map_memory" : "1.2kb",
          "version_map_memory_in_bytes" : 1328,
          "fixed_bit_set" : "63.6mb",
          "fixed_bit_set_memory_in_bytes" : 66745592
        }
      }
    }
  }

}

Чёт как то до хуя получается...

Попробуем уменьшить кол-во сегментов, на шард...

Для начала необходимо выяснить какой индекс имеет больше всех сегментов:

curl --silent 'http://localhost:9200/_cat/segments?v'|awk 'NR!=1 {a[$1]++}END {for (i in a) print i,a[i]}'|sort -k 2 -n

compare 31

catalog_230 33

reglament 37

ssa 47

house_2(mar_23) 96

house_3(apr_6) 104

Итого видим что больше всех сегментов у индекса house_3(apr_6) поэтому начнём с него...
curl -XPOST 'http://localhost:9200/house_3(apr_6)/_optimize?max_num_segments=2' 
 опять же следует обратить внимание что это кол-во на шард!
(тут следует адский процесс...)
мониторить кол-во сегментов можно так же командой
curl --silent 'http://localhost:9200/_cat/segments?v'|awk 'NR!=1 {a[$1]++}END {for (i in a) print i,a[i]}'|sort -k 2 -n)

Заметочка: Если мониторить через kopf размер индекса будет расти по мере merge сегментов. Т.к. kopf похоже так же суммируется еще не доступный для поиска сегмент в который происходит merge.




Походу выполнения можно добавить настройки:
indices.store.throttle.type: none - индексировать на столько быстро насколько позволяет диск
indices.store.throttle.max_bytes_per_sec: 100mb - или ограничить

Вообщем то так же можно посмотреть сколько занимает в памяти каждый сегмент ну и прочую херню по нему:
curl -XGET 'http://localhost:9201/test/_segments?verbose=true'

Отсортировать по самым сожравшим память сегментам:
curl --silent 'http://localhost:9201/_cat/segments?v'|sort -k 10 -n

Суммарно по каждому индексу сколько сегменты отъели в памяти:
curl --silent 'http://test1:9244/_cat/segments?v'|awk '/10.64.191.71/ {a[$1]++;b[$1]=b[$1]+$10} END {for (i in a) {print i,a[i],b[i]/1024/1024}}'|sort -k 3 -n

Тут вообщем то всё просто в awk мы передаём IP нашей тачки, если у нас 2 ноды то IP той ноды на которой мы хотим посмотреть сколько занимают сегменты в памяти.
(на хуя всё это делать если можно посмотреть это в шардах ну да ладно).

Ну да хуй с ним едем дальше....

Часть 2. query performance

Эластику дано 32гига оперативки (серверов всего 4 соответственно у индекса 3 реплики).
Есть индекс типа catalog_1056. По нему гоняется запрос кучей фильтров
(запрос огромный так что я даже не буду сюда его копировать).
Как же работает кэш, запросы и реплики и т.д. ( а оговоримся что у нас какай то ебанутая версия с собственными пачами, но хуй его знает что там , мб оно и не влияет).

Смотрим как дела с кэшем
curl -XGET 'http://localhost:9201/_cat/indices/catalog_1056?h=i,docs.count,docs.deleted,fielddata.memory_size,filter_cache.memory_size,segments.count'
catalog_1056 12871645 3380630 0b 0b 83 
Нас тут интересует последние 4 цифры, это  размер fielddata cache, filter cache и кол-во сегментов

Посмотрим туже херню по shard:
curl --silent 'http://localhost:9201/_cat/shards/catalog_1056?h=index,shard,prirep,node,fielddata.memory_size,filter_cache.memory_size'
catalog_1056 0 r ESM1 0b     0b
catalog_1056 0 p ESM3 0b    0b
catalog_1056 0 r ESM4 0b     0b
catalog_1056 0 r ESM2 0b     0b
Как мы видим всё пусто нет ни fielddata cache, ни filtercache.

1. Первый запрос.

{ "took": 12286, "timed_out": false, "_shards": { "total": 1, "successful": 1, "failed": 0 },

catalog_1056 0 r ESM1 90mb 12.3mb
catalog_1056 0 p ESM3     0b     0b
catalog_1056 0 r ESM4     0b     0b
catalog_1056 0 r ESM2     0b     0b

2. Второй запрос

"took": 16582, "timed_out": false, "_shards": { "total": 1, "successful": 1, "failed": 0 }

catalog_1056 0 r ESM1   90mb 12.3mb
catalog_1056 0 p ESM3 80.8mb   11mb
catalog_1056 0 r ESM4     0b     0b
catalog_1056 0 r ESM2     0b     0b

3. Третий запрос
"took": 8906, "timed_out": false, "_shards": { "total": 1, "successful": 1, "failed": 0 },

catalog_1056 0 r ESM1   90mb 12.3mb
catalog_1056 0 p ESM3 80.8mb   11mb
catalog_1056 0 r ESM4  102mb 12.7mb
catalog_1056 0 r ESM2     0b     0b
 

4. Четвертый запрос

"took": 6841, "timed_out": false, "_shards": { "total": 1, "successful": 1, "failed": 0 },

catalog_1056 0 r ESM1   90mb 12.3mb
catalog_1056 0 p ESM3 80.8mb   11mb
catalog_1056 0 r ESM4  102mb 12.7mb
catalog_1056 0 r ESM2 89.3mb 11.8mb

5. Пятый запрос Тут кэши на всех шардах заполнились и ура всё заработало.

"took": 1391, "timed_out": false, "_shards": { "total": 1, "successful": 1, "failed": 0   

Итого как мы видим, запрос отправляется не на все шарды, на один конкретный хотя всё запросы были сделаны с одной ноды(которая как говорит дока становится кординационной т.к мы на неё пуляем запросы). Если мы почистим кэш и выполним еще раз будет обсолютно тоже самое, т.е запрос будет "гулять" по нодам, как утверждает дока round robin.

Забавно но по моим наблюдениям если у вас запрос выдёт:

catalog_1056 0 r ESM1 95.9mb 12.3mb 0 0 0
catalog_1056 0 p ESM3 80.8mb   11mb 0 0 0
catalog_1056 0 r ESM4  102mb 12.7mb 0 0 0
catalog_1056 0 r ESM2 89.3mb 11.8mb 0 0 0  

То и запрос к этому индексу будет раскидан аналогичным образом т.е:

1 - esm1 - ~1.5s

2 - esm3 - ~0.7s

3 - esm4 - ~1.4s

4 - esm2 - ~0.7s

Хуй знает от чего зависит время ответа, загруженность ноды сеть и т.д не знаю что придумать.

Далее было бы интересно посмотреть влияние кол-ва сегментов на запрос, поэтому не будем чистить кэш (он и сам почистится после merge) и просто выполним 2 команды.

 curl -XPOST 'http://localhost:9201/catalog_1056/_optimize?max_num_segments=1'

(для elastiсsearch 5 это называется force merge).

Выполняем тот же запрос видим  что кэши заполнились:

И сам запрос стал выполняться в разы быстрее:

"took": 2619, "timed_out": false, "_shards": { "total": 1, "successful": 1, "failed": 0 }, - это время при не заполненных кэшах.

curl --silent 'http://localhost:9201/_cat/shards/catalog_1056?h=index,shard,prirep,node,fielddata.memory_size,filter_cache.memory_size,sqc,sfc,gc,dc' 

(тут я добавил 4 поля текущее кол-во quary current, fetch current, get current, кол-во документов).

catalog_1056 0 r ESM1 72.4mb 10.7mb 0 0 0 12871645
catalog_1056 0 p ESM3 72.4mb 10.7mb 0 0 0 12871645
catalog_1056 0 r ESM4 72.4mb 10.7mb 0 0 0 12871645
catalog_1056 0 r ESM2 72.4mb 10.7mb 0 0 0 12871645
 

Блять пизда интернет сдох..... 

Короче после проверки(после того как на всех шардах кэш заполнен) по всем шардам запрос занимает от ~0.4-0.6s!!!

Что само по себе в разы лучше... Тем не менее всё равно долго...

To be continue ... (хотя я хуй знает что можно сделать...) переписать запрос???...

А и тут я придумал что надо проверить... Надо добавить индексу шардов т.е сейчас 1 pri и 3 rep.

Соответственно было бы интересно сделать скажем 2 pri.

Хотя где то была статья что это гавно идея... когда нить продолжу..

Часть 3. Fielddata vs Filtercache(el1.4) (node quary cache el5+)

Продолжаем расследование... Тут закралась мысль, т.к у нас немного ебанутый индекс и не очень понятно на кой хуй ему фильтер кэш, т.к фильтров бесконечное множество, да и данную эластику память лучше заюзать для fielddata другого индекса.

Ну и вообщем то интересно проверить на запросе с кучей фильтром как оно будет жить.

1. Оба кэша "существуют" и считаем что они заполнены (fielddata preload!)

indices.cache.filter.size: 10%
indices.fielddata.cache.size: 40%
indices.breaker.fielddata.limit: 43%

На самом деле насрать какие тут настройки т.к у нас при выполнении запроса кэш заполняется на 80Mb

Выполняем запрос:

                                                      Fielddata Filter

catalog_1056 0 p oracleadmintst  80.8mb    8.7mb 0 0 0 12871645

  "took": 498, "timed_out": false, "_shards": { "total": 1, "successful": 1, "failed": 0 },

2. Вырубаем filter cache:

indices.cache.filter.size: 0
indices.fielddata.cache.size: 60%

indices.breaker.fielddata.limit: 61%

Выполняем запрос:

                                                      Fielddata Filter

catalog_1056 0 p oracleadmintst  80.8mb    0b 0 0 0 12871645

  "took": 703, "timed_out": false, "_shards": { "total": 1, "successful": 1, "failed": 0 },

Гавно какой то...
Вообщем следует признать что кэш нужен....

Чёт я еще хотел написать но решил что в пизду... Когда нибудь потом...

curl localhost:9201/_cat/thread_pool?h=host,search.active,search.queue,get.active,get.queue,bulk.active,bulk.queue,index.active,index.queue