# Segments count и Heap size **URL:** \ **Category:** Вопросы на русском языке\ **Created:** [November 11, 2016, 8:14am UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767 "2016-11-11T08:14:44Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [November 11, 2016, 8:14am UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/1 "2016-11-11T08:14:44Z")
Всем привет! Ребята, на данный момент мы бьем индексы по дням и у нас получилось около 2000-2500 индексов. На машине 64 Гб ОЗУ, из них 31 Гб выделен под Heap. Данных у нас уже 13 Тб. На версии 2.4.1 ElasticSearch уже начинал умирать и часто запускал GC. После обновления до 5.0 он умирает уже после 15 минут запуска и судя по графику дело в количестве segments - их около 30 000. Правильно ли я понимаю что, что чем больше segments, тем большее потребляется Heap и нам нужно произвести optimize или forcemerge для индексов? Можно ли временно переместить папки с индексами чтобы отключить их? Спасибо ---
**Author:** ![rusty](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@rusty](https://discuss.elastic.co/u/rusty)\ **Post date:** [November 11, 2016, 10:01am UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/2 "2016-11-11T10:01:25Z")
Привет, папки с индексами можно не перемещать, достаточно закрыть "ненужные" индексы. Сегментов действительно много, но надо смотреть что показывает статистика по ноде: > [@ELK suddenly colapsed](https://discuss.elastic.co/t/elk-suddenly-colapsed/48414/4): > > You can also can close unused indexes (their data become unavailable, but it would free up the memory) Run curl -XGET "localhost:9200/\_stats?pretty" and get a look at all - segments - memory\_in\_bytes. Divide memory\_in\_bytes by number of nodes and you'll get rough estimation of memory consumption on each node. For more details, please, follow these links: [topic1](https://discuss.elastic.co/t/segments-memory-in-bytes-excessively-large-with-allot-of-open-indices/40622), [topic2](https://discuss.elastic.co/t/segments-memory-in-bytes-goes-down-after-reduction-of-segments-restart/41258) и хороший коммент про минусы закрытия индексов: > [@ELK suddenly colapsed](https://discuss.elastic.co/t/elk-suddenly-colapsed/48414/5): > > Don't do that unless you have to though: closed indices are no longer managed by ES. Meaning if a node dies with closed index shards, they will not be recovered elsewhere. Say you close an index for 2 months and you had 2 node failures in that time .. it could just be that both primary and replica shard X were discarded and never recovered. You try to open the index one day and voila: it's Red and you lost data. Just saying wink ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [November 11, 2016, 11:17am UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/3 "2016-11-11T11:17:37Z")
Спасибо. Сейчас хотим по очереди оптимизировать/мёржить индексы, какие значения index.merge.scheduler.max\_thread\_count index.merge.policy.segments\_per\_tier мне выставить чтобы использовать, допустим, 24 потока? ---
**Author:** ![rusty](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@rusty](https://discuss.elastic.co/u/rusty)\ **Post date:** [November 11, 2016, 12:50pm UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/4 "2016-11-11T12:50:38Z")
Можно попробовать оптимизировать до 1 сегмента часть старых и посмотреть на что это повлияет, сделать можно через [forcemerge API](https://www.elastic.co/guide/en/elasticsearch/reference/5.0/indices-forcemerge.html). Другой вариант: делать меньше индексов и шардов (сколько их сейчас на индекс?), потому что, на индекс получается не так уж и много сегментов (30k/2,5k=12 сегментов) и, вообще, индексы небольшие (примерно по 5GB, их можно увеличить до 30-50GB, а если нет сети и в старые не пишется и еще больше, повлияет только на скорость восстановления после сбоя или некорректного перезапуска кластера). ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [November 11, 2016, 1:21pm UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/5 "2016-11-11T13:21:02Z")
Сейчас 1 шарда на индекс. > делать меньше индексов Бить по месяцам? У нас на каждый тип лога пишет свой индекс и все это еще и по дням. Таким образом размеры индексов не равномерны - есть тип лога индекс которого за день за последний месяц 50-95 Гб. В старые индексы не пишется. Нода одна. Как сейчас максимально можно увеличить скорость мёржинга? Спасибо ---
**Author:** ![rusty](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@rusty](https://discuss.elastic.co/u/rusty)\ **Post date:** [November 11, 2016, 2:34pm UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/6 "2016-11-11T14:34:02Z")
Про merge врядли что-то подскажу, может кто-то из модераторов или разработчиков сможет сказать именно по 5-ке, они постепенно выпиливали все настройки и что осталось - непонятно. Подброшу еще одну возможность выиграть по памяти: добавлять памяти на сервер и разворачивать еще одну дата-ноду (либо сделать на каждую дата-ноду по 24-26GB памяти (48-52 из 64) и пожертвовать памятью ОС и файл-кешем, при этом желательно не влезать в swap, `vm.swappiness = 1`) на этом же сервере, но с хранением данных в другой директории. Ограничение: позволяет ли сервер по диску и CPU это сделать или нет? У нас работает от 1 до 3 инстансов на каждом сервере кластера (но у нас машины это позволяют). ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [November 11, 2016, 2:56pm UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/7 "2016-11-11T14:56:11Z")
Я думаю, прежде чем принимать какие-то меры, надо разобраться в чем собственно проблема. 30000 сегментов на 2000 шард - это вполне нормально. С другой стороны, если у вас только одна нода в кластере, то 2000 шард - это перебор. Вы не могли бы прислать выводы [node stats](https://www.elastic.co/guide/en/elasticsearch/reference/5.0/cluster-nodes-stats.html) и [node info](https://www.elastic.co/guide/en/elasticsearch/reference/5.0/cluster-nodes-info.html)? Из них должно быть более ясно куда память уходит. ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [November 11, 2016, 7:50pm UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/8 "2016-11-11T19:50:33Z")
Добрый день, Игорь Сейчас подключил половину индексов и все они открыты node info: [https://yadi.sk/i/OWE1IOxcyRTro](https://yadi.sk/i/OWE1IOxcyRTro) node stats: [https://yadi.sk/i/4OwbyGZuyRTs6](https://yadi.sk/i/4OwbyGZuyRTs6) Спасибо ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [November 11, 2016, 8:50pm UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/9 "2016-11-11T20:50:24Z")
Забыл упомянуть: на каждый тип лога у нас создан и обновляется алиас по маске: logtype\* ---
**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\ **Post date:** [November 11, 2016, 9:07pm UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/10 "2016-11-11T21:07:37Z")
Посмотрели на статистику. Картина, похоже, такая получается: ежедневные индексы приводят к большому количеству шард, что в свою очередь приводит к большому количеству сегментов, и поскольку каждый сегмент это маленький инвертированный индекс для каждого поля, все это ведет к большому расходу памяти. Отсюда возможные решения: 1. Увеличить количество памяти добавлением еще одной или двух нод. Это самый простой способ. 2. Перейти на недельные или даже месячные индексы. Это уменьшить количество шард и таким образом количество сегментов. 3. Используя force merge сократить количество сегментов в старых шардах до одного сегмента на шарду. Процесс можно автоматизировать с помощью программы [curator](https://www.elastic.co/guide/en/elasticsearch/client/curator/current/forcemerge.html), который добавить в cron и запускать каждую ночь на только что созданном индексе. 4. Выкинуть из индекса ненужные поля (особенно поля с большим количеством уникальных значений) ---
**Author:** ![Denis\_Lamanov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/denis_lamanov/32/13111_2.png) [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)\ **Post date:** [November 11, 2016, 9:10pm UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/11 "2016-11-11T21:10:36Z")
Спасибо, Игорь Видимо реализуем первые 3 пункта. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [December 9, 2016, 9:10pm UTC](https://discuss.elastic.co/t/segments-count-heap-size/65767/12 "2016-12-09T21:10:52Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.