Одна нода использует больше места на ssd, чем вторая в ES 2.0


(Мишка Карташов) #1

Здравствуйте.
Из-за нехватки места на SSD под индекс решил попробовать версию 2.0, в которой появился deflate. Удалось снизить используемое место почти в два раза, но возникла такая проблема - периодически одна из нод начинает вырываться вперед по используемому месту. Если дать команду optimize, то место высвобождается. На графике это выглядит это так:

Индексы с TTL 24 часа, четыре с фиксированными именами, и четыре с датой в конце.
В 1.7 место использовалось равномерно обеими нодами. Может, в 2.0 появилась какая-то волшебная настройка, которую я пропустил в документации?
Спасибо


(Igor Motov) #2

Есть несколько вопросов/уточнений.

  1. TTL у вас как реализован? Через параметр ttl или вы весь индекс удаляете каждый день?
  2. Я не очень понял график. Во сколько вы optimize на этом графике запустили?
  3. Вы настройки merge throttling в 1.7 меняли?

(Мишка Карташов) #3
  1. Через параметр ttl
  2. В 10:40, в 14:30. Потом поставил в крон каждый час
  3. Я пробовал их менять, когда пытался часть данных оставить на ssd, а часть на sas. Производительность не устроила и я вернул все по умолчанию. Сейчас конфиг такой:
    cluster.routing.allocation.node_initial_primaries_recoveries: 140 (осталось с эксперимента с почасовыми индексами)
    cluster.routing.allocation.node_concurrent_recoveries: 400
    indices.recovery.max_bytes_per_sec: 100mb
    bootstrap.mlockall: true
    indices.memory.index_buffer_size: 35%
    index.translog.flush_threshold_ops: 100000
    threadpool.search.type: fixed
    threadpool.search.size: 25
    threadpool.search.queue_size: 3000
    threadpool.index.type: fixed
    threadpool.index.size: 16
    threadpool.index.queue_size: 200
    threadpool.bulk.type: fixed
    threadpool.bulk.size: 16
    threadpool.bulk.queue_size: 500
    index.refresh_interval: "1m"
    index.compound_on_flush: false
    index.compount_format: false
    index.warmer.enabled: false

(Igor Motov) #4

Что-то я не пойму 10:40 это когда optimize завершился или когда он начался? По графику, такое впечатление что optimize начался около 7-ми.

Запуск optimize раз в час - это не ответ. Хотелось бы понять, что там происходит. А вы не могли бы выключить optimize на время, запустить curl "localhost:9200/_nodes/stats" в нормальной состоянии системы, потом дождаться пока одна из нод не начнет расти и запустить эту команду еще пару раз?


(Мишка Карташов) #5

Как только я запускал curl -XPOST 'http://localhost:9200/my_index*/_optimize' в ответ через несколько секунд прилетало acknowledge:true, а место сразу же высвобождалось. Это было в 10:40, в 14:30, когда резко упало занятое место сначала на одной ноде, потом на второй.
Свой "костыль" с optimize я вчера вечером выключил, но ночью ноды почему-то передрались из-за того, кто из них мастер, вылечилось рестартом и удалением одного из индексов.
Сейчас показания между нодами почти не расходятся, вывод nodes/stats сохранил сюда http://pastebin.com/cwVFjZNq, иначе ругается на размер сообщения


(Igor Motov) #6

Если проблема повторится, запустите пожалуйста _nodes/stats и my_index*/_stats, сохраните результат и потом запустите my_index*/_flush вместо _optimize и повторите _nodes/stats и my_index*/_stats.

Сложно сказать, что там происходит. Есть теория, что по какой-то причине translog застрял и optimize его подтолкнул, но почему он застрял - совсем не понятно.


(Мишка Карташов) #7

Повторилось, flush помог:


node stats до
http://pastebin.com/8NY0st0e
После
http://pastebin.com/UPQVDkTh

По index stats случайно затер что было до, осталось только то что было после:
http://pastebin.com/9fkf52aV

Как воспроизведется в следующий раз, сделаю my_index*/_stats до команды flush

Утром сегодня внес изменения в конфигурацию, добавил
threadpool.bulk.queue_size: 10000
indices.store.throttle.max_bytes_per_sec: 150mb
indices.memory.index_buffer_size: 40%


(Igor Motov) #8

Интересно. А не могло так получиться, что вы перед установкой 2.0 выключили flush и потом забыли его включить? У вас нигде index.translog.disable_flush в установках индексов не появляется?


(Мишка Карташов) #9

Нет, темплейты у всех индексов одинаковые, за исключением полей:
{
"template_per_index": {
"order": 0,
"template": "my_index*",
"settings": {
"index": {
"codec": "best_compression",
"cache": {
"field": {
"type": "soft"
}
},
"refresh_interval": "1m",
"store": {
"compress": {
"stored": "true"
}
}
}
},
"mappings": {
"my_index": {
"_ttl": {
"default": "24h",
"enabled": true
},
"_all": {
"enabled": false
},
}
},
"aliases": {}
}
}

У всех текстовых полей стоит
"index": "not_analyzed",
"type": "string",
"doc_values": false

В elasticsearch.yml у меня flush фигурирует только в настройках
index.translog.flush_threshold_ops: 100000
index.compound_on_flush

Сейчас пока место не разъезжается - подожду вечера, видимо, это начинает проявляться под нагрузкой


(Igor Motov) #10

А что elasticsearch выдает если запустить curl localhost:9200/_settings?


(Мишка Карташов) #11

Вот index stats до flush:
http://pastebin.com/5jNb5etD
_settings выдает настройки всех индексов, они одинаковые: http://pastebin.com/qq8wPdeL

Еще подметил - расползаться место начинает после рестарта одной из нод - сегодня утром одна из них склеилась от нехватки памяти, ее перезапустили, после этого место на ноде, которую рестартовали рвануло вверх.


(Мишка Карташов) #12

Попутно еще заметил одну странность - не удалились данные по ttl, сделал запрос к старому индексу, а там ttl отрицательный:
"hits": {
"total": 52846179,
"max_score": 1,
"hits": [
{
"_index": "myindex-2015.10.16",
"_type": "myindex",
"_id": "AVBwavtwvcZGdpan36L7",
"_score": 1,
"_ttl": -82358358,
"_source": {
"@timestamp": "2015-10-16T11:31:09.102Z",
"info": {
"PID": "8F23E3FC-72C0-EF84-09A1-A947DE8AC920",
"CID": "0E881553-589D-42D7-8DE6-7C21D5300F5B",
"N": 9,
"IP": "88.200.214.13",
"ADID": {
"msg": "null",
"num": "0"
}
},
"error": {}
}
},


(Igor Motov) #13

Это всегда происходить при перезагрузки ноды? Если да, то это нормально - это связано с тем что файлы между нодами синхронизируются и в связи с тем, что у вас очень не оптимальное использование ttl файлы на разных нодах у вас становятся разными очень быстро - в результате при перезагрузке по сути создается полная копия каждой шарды и перед тем как старая копия удаляется. Однако, в этой ситуации flush не должен помогать.

Я пытаюсь воспроизвести эту проблему на моей машине и чтобы лучше понять что там происходит, у меня еще пара вопросов:

  1. а наблюдали ли вы эту проблему когда-нибудь без перезагрузки второй ноды
  2. вы не могли бы поставить логер index.translog в TRACE и прислать мне логи (можно по email)
  3. когда это еще раз произойдет, вместе со stats вы не могли бы запустить ls -lR в директории, где elasticsearch хранит данные
  4. вы не могли бы более подробно описать, как часто у вас индексируются записи и в каком количестве

(Мишка Карташов) #14
  1. Нет, только после перезагрузки. При чем, если перезапустить их обе одновременно, то и место начинает расти на обоих. Но, расти оно начинает только после того, как кластер становится зеленым и при команде flush )место высвобождается. При рестарте ноды место тоже освобождается.
  2. https://yadi.sk/i/VPQ13C4gjqjhT
  3. ls - https://yadi.sk/d/GEpZn6NGjqkGV
    index stats https://yadi.sk/i/bCdftveOjqjvG
    node stats https://yadi.sk/i/vskZegh4jqkNf
    Увы, пропустили момент когда утекло место и все упало, так что вывод всех команд уже после рестарта. Попробую подловить по-раньше, до того, как место закончится.
  4. Записи индексируются непрерывно. Если верить кибане, в пике примерно 10 000 событий в секунду, ночью в районе 1000. Парсер самописный, отправляет bulk каждые 30 секунд

(Igor Motov) #15

Очень бы хотелось увидеть вывод ls -lR когда диск не свободен, и выводы /_segments в дополнение к index и node stats. И еще пара вопросов.

  1. после того, как вы flush запускаете проблема полностью исчезает до следующей перезагрузки?
  2. Зачем вам TTL, если вы все-равно новый индекс каждый день создаете?

(Мишка Карташов) #16

Все сделал: https://yadi.sk/d/RJ-CM_AVjuJHw
Для теста полностью удалил все индексы, сутки все было в порядке. Сегодня днем рестартанул одну ноду, к вечеру она отъела на 100GB больше, чем та, которую я не трогал.

  1. Нет, после flush место опять начинает расти. Нормально фунциклирует только новый индекс, старый растет по мере наполнения и потом не удаляет данные по ttl, который становится отрицательным. Удаляю вручную.
  2. Нужны данные за последние 24 часа, а 48 часов на одном ssd не умещаются. Единственное, можно попробовать почасовые индексы сделать. Новый индекс каждый день создаем для того, чтобы к новому индексу применялся новый маппинг - формат меняется достаточно динамично.

(Igor Motov) #17

Спасибо за данные. Будем изучать.

Я думаю, что переход на почасовой индекс - это правильно решение. Ttl у вас всю производительность убивает.


(system) #18