Здравствуйте.
Из-за нехватки места на SSD под индекс решил попробовать версию 2.0, в которой появился deflate. Удалось снизить используемое место почти в два раза, но возникла такая проблема - периодически одна из нод начинает вырываться вперед по используемому месту. Если дать команду optimize, то место высвобождается. На графике это выглядит это так:
Индексы с TTL 24 часа, четыре с фиксированными именами, и четыре с датой в конце.
В 1.7 место использовалось равномерно обеими нодами. Может, в 2.0 появилась какая-то волшебная настройка, которую я пропустил в документации?
Спасибо
Есть несколько вопросов/уточнений.
- TTL у вас как реализован? Через параметр ttl или вы весь индекс удаляете каждый день?
- Я не очень понял график. Во сколько вы optimize на этом графике запустили?
- Вы настройки merge throttling в 1.7 меняли?
- Через параметр ttl
- В 10:40, в 14:30. Потом поставил в крон каждый час
- Я пробовал их менять, когда пытался часть данных оставить на 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
Что-то я не пойму 10:40 это когда optimize завершился или когда он начался? По графику, такое впечатление что optimize начался около 7-ми.
Запуск optimize раз в час - это не ответ. Хотелось бы понять, что там происходит. А вы не могли бы выключить optimize на время, запустить curl "localhost:9200/_nodes/stats" в нормальной состоянии системы, потом дождаться пока одна из нод не начнет расти и запустить эту команду еще пару раз?
Как только я запускал curl -XPOST 'http://localhost:9200/my_index*/_optimize' в ответ через несколько секунд прилетало acknowledge:true, а место сразу же высвобождалось. Это было в 10:40, в 14:30, когда резко упало занятое место сначала на одной ноде, потом на второй.
Свой "костыль" с optimize я вчера вечером выключил, но ночью ноды почему-то передрались из-за того, кто из них мастер, вылечилось рестартом и удалением одного из индексов.
Сейчас показания между нодами почти не расходятся, вывод nodes/stats сохранил сюда http://pastebin.com/cwVFjZNq, иначе ругается на размер сообщения
Если проблема повторится, запустите пожалуйста _nodes/stats и my_index*/_stats, сохраните результат и потом запустите my_index*/_flush вместо _optimize и повторите _nodes/stats и my_index*/_stats.
Сложно сказать, что там происходит. Есть теория, что по какой-то причине translog застрял и optimize его подтолкнул, но почему он застрял - совсем не понятно.
Повторилось, 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%
Интересно. А не могло так получиться, что вы перед установкой 2.0 выключили flush и потом забыли его включить? У вас нигде index.translog.disable_flush в установках индексов не появляется?
Нет, темплейты у всех индексов одинаковые, за исключением полей:
{
"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
Сейчас пока место не разъезжается - подожду вечера, видимо, это начинает проявляться под нагрузкой
А что elasticsearch выдает если запустить curl localhost:9200/_settings?
Вот index stats до flush:
http://pastebin.com/5jNb5etD
_settings выдает настройки всех индексов, они одинаковые: http://pastebin.com/qq8wPdeL
Еще подметил - расползаться место начинает после рестарта одной из нод - сегодня утром одна из них склеилась от нехватки памяти, ее перезапустили, после этого место на ноде, которую рестартовали рвануло вверх.
Попутно еще заметил одну странность - не удалились данные по 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": {}
}
},
Это всегда происходить при перезагрузки ноды? Если да, то это нормально - это связано с тем что файлы между нодами синхронизируются и в связи с тем, что у вас очень не оптимальное использование ttl файлы на разных нодах у вас становятся разными очень быстро - в результате при перезагрузке по сути создается полная копия каждой шарды и перед тем как старая копия удаляется. Однако, в этой ситуации flush не должен помогать.
Я пытаюсь воспроизвести эту проблему на моей машине и чтобы лучше понять что там происходит, у меня еще пара вопросов:
- а наблюдали ли вы эту проблему когда-нибудь без перезагрузки второй ноды
- вы не могли бы поставить логер index.translog в TRACE и прислать мне логи (можно по email)
- когда это еще раз произойдет, вместе со stats вы не могли бы запустить ls -lR в директории, где elasticsearch хранит данные
- вы не могли бы более подробно описать, как часто у вас индексируются записи и в каком количестве
- Нет, только после перезагрузки. При чем, если перезапустить их обе одновременно, то и место начинает расти на обоих. Но, расти оно начинает только после того, как кластер становится зеленым и при команде flush )место высвобождается. При рестарте ноды место тоже освобождается.
- https://yadi.sk/i/VPQ13C4gjqjhT
- ls - https://yadi.sk/d/GEpZn6NGjqkGV
index stats https://yadi.sk/i/bCdftveOjqjvG
node stats https://yadi.sk/i/vskZegh4jqkNf
Увы, пропустили момент когда утекло место и все упало, так что вывод всех команд уже после рестарта. Попробую подловить по-раньше, до того, как место закончится. - Записи индексируются непрерывно. Если верить кибане, в пике примерно 10 000 событий в секунду, ночью в районе 1000. Парсер самописный, отправляет bulk каждые 30 секунд
Очень бы хотелось увидеть вывод ls -lR когда диск не свободен, и выводы /_segments в дополнение к index и node stats. И еще пара вопросов.
- после того, как вы flush запускаете проблема полностью исчезает до следующей перезагрузки?
- Зачем вам TTL, если вы все-равно новый индекс каждый день создаете?
Все сделал: https://yadi.sk/d/RJ-CM_AVjuJHw
Для теста полностью удалил все индексы, сутки все было в порядке. Сегодня днем рестартанул одну ноду, к вечеру она отъела на 100GB больше, чем та, которую я не трогал.
- Нет, после flush место опять начинает расти. Нормально фунциклирует только новый индекс, старый растет по мере наполнения и потом не удаляет данные по ttl, который становится отрицательным. Удаляю вручную.
- Нужны данные за последние 24 часа, а 48 часов на одном ssd не умещаются. Единственное, можно попробовать почасовые индексы сделать. Новый индекс каждый день создаем для того, чтобы к новому индексу применялся новый маппинг - формат меняется достаточно динамично.
Спасибо за данные. Будем изучать.
Я думаю, что переход на почасовой индекс - это правильно решение. Ttl у вас всю производительность убивает.