# Конфигурация Threadpool

**URL:** <https://discuss.elastic.co/t/threadpool/51054>\
**Category:** Вопросы на русском языке\
**Created:** [May 26, 2016, 11:37am UTC](https://discuss.elastic.co/t/threadpool/51054 "2016-05-26T11:37:46Z")\
**Posts on this page:** 9\
**Page:** 2

<div class="post-metadata">

**Author:** ![Evgeny\_Lazarev](https://avatars.discourse-cdn.com/v4/letter/e/d07c76/32.png) [@Evgeny\_Lazarev](https://discuss.elastic.co/u/Evgeny_Lazarev)\
**Post date:** [June 2, 2016, 11:24am UTC](https://discuss.elastic.co/t/threadpool/51054/21 "2016-06-02T11:24:53Z")

</div>

> [@ei-grad](#):
>
> Покажи elasticsearch.yml?

```
discovery.zen.ping.unicast.hosts: ["makea30","makea31","makea32","makea33","makea34"]
discovery.zen.ping.multicast.enabled: false
 
bootstrap.mlockall: true
node.master: true
 
cluster.name: test-es-cluster
node.name: "makea30"
 
network.host: makea30
path.data: ["/data1/es", "/data2/es"]
 
threadpool.bulk.queue_size: 5000
threadpool.index.queue_size: 5000
 
indices.store.throttle.max_byte_per_sec: 30Gb
indices.memory.shard_inactive_time: 30m
indices.memory.index_buffer_size: 30%

```

Первые 5 машин - мастера. Остальные 4 - дата ноды. Конфигурация там аналогична.  
Маплю каждую ноду на 2 диска (пересекаются между нодами).

Индекс создаю со следующими параметрами:  
"index":{  
"refresh\_interval":"-1",  
"number\_of\_shards":"50",  
"number\_of\_replicas":"0",  
"translog":{  
"durability":"async",  
"interval":"60s",  
"sync\_interval":"60s",  
"flush\_threshold\_size":"20Gb"  
},  
"unassigned.node\_left.delayed\_timeout": "10m",  
"store.stats\_refresh\_interval": "30s",  
"merge.scheduler.max\_thread\_count": "1",  
"merge.policy.floor\_segment": "4Gb",  
"merge.policy.max\_merge\_at\_once": "15",  
"merge.policy.segment\_per\_tier": "30",  
"merge.policy.max\_merged\_segment": "30Gb"  
}

forcemerge проверю.

Спарк льет через 30-ю ноду. Cloudera-менеджер затыки на сеть не показывает.

Про FS и диски ничего сказать не могу.

В такой конфигурации, в целом, уже достаточно хорошая скорость.  
Единственное, что бросается в глаза - на некоторых нодах периодически случаются затыки в IO, балковая очередь растет (но не переполняется). Не нравится мне это тем, что когда такое происходит, остальные узлы кластера начинают простаивать.

---

<div class="post-metadata">

**Author:** ![ei-grad](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ei-grad/32/5775_2.png) [@ei-grad](https://discuss.elastic.co/u/ei-grad)\
**Post date:** [June 2, 2016, 2:29pm UTC](https://discuss.elastic.co/t/threadpool/51054/22 "2016-06-02T14:29:13Z")

</div>

> Первые 5 машин - мастера. Остальные 4 - дата ноды

Они у тебя не выделенные мастера, а master+data? Попробуй запустить master-ноды в отдельных процессах на отдельных портах (или адресах).

Обычно 3х мастеров достаточно, 5 - хуже.

> Маплю каждую ноду на 2 диска (пересекаются между нодами).

Два диска в смысле в зеркале, или в смысле просто по два отдельных тома?

edit: а, вижу что два отдельных. фиг знает, может и есть смысл, но я бы один оставил... ты тестил? с одним медленнее?

> "flush\_threshold\_size":"20Gb"

Оно правда помогает? Вроде дефолтных 512Мб вполне достаточно должно быть, если spark по 30мб bulk'и шлет. Ну и памяти у него столько под транслог всё равно нет, я бы ограничил хотя бы в 2Гб (а лучше бы не трогал). Не понимаю как большой буффер для translog может улучшить производительность, его же всё равно писать на диск потом. Чанка в 512Мб обычно достаточно 🙂. Тем более у тебя всё равно потом fsync только раз в 60 секунд - java-вский буффер просто уйдет в буффер ОС и попадет на диск только в течение минуты. Скорее всего уход в IO и лок кластера у тебя как раз из за этого.

> "number\_of\_shards":"50",  
> "number\_of\_replicas":"0",

Извращенец :-). Но у меня самого та же фигня, правда вместо кучи шардов - куча индексов... У тебя действительно одна машина с необходимым объемом записи не справляется? А то с таким конфигом смысла в кластере не много.

Если есть возможность расшардироваться на уровне Spark (и раскидать данные по нескольким индексам, а не шардам в одном индексе) - просто запусти на каждой машине отдельный single-node elastic, прогони импорт (всё линейно замасштабируется, эластик отработает на полную), а потом уже в кластер объединяй.

---

<div class="post-metadata">

**Author:** ![Evgeny\_Lazarev](https://avatars.discourse-cdn.com/v4/letter/e/d07c76/32.png) [@Evgeny\_Lazarev](https://discuss.elastic.co/u/Evgeny_Lazarev)\
**Post date:** [June 2, 2016, 2:46pm UTC](https://discuss.elastic.co/t/threadpool/51054/23 "2016-06-02T14:46:25Z")

</div>

> [@ei-grad](#):
>
> Они у тебя не выделенные мастера, а master+data

да, мастер+дата

> [@ei-grad](#):
>
> edit: а, вижу что два отдельных. фиг знает, может и есть смысл, но я бы один оставил... ты тестил? с одним медленнее?

планирую потестить.

> [@ei-grad](#):
>
> Извращенец :-). Но у меня самого та же фигня, правда вместо кучи шардов - куча индексов... У тебя действительно одна машина с необходимым объемом записи не справляется? А то с таким конфигом смысла в кластере не много.

У меня данных много. При репликации в 1 это 20ТБ. ES пишет сутки, а то и больше, так как на сервере физически есть не только ES. Мне проще потом проставить реплику. Тем более, что однажды один диск стал недоступным и все вообще легло из-за рекавери. Проблема ещё и в том, что эти 10ТБ начальные - это только тестовый вариант. Реальных данных ещё больше.

> [@ei-grad](#):
>
> Если есть возможность расшардироваться на уровне Spark (и раскидать данные по нескольким индексам, а не шардам в одном индексе) - просто запусти на каждой машине отдельный single-node elastic, прогони импорт (всё линейно замасштабируется, эластик отработает на полную), а потом уже в кластер объединяй

Вот этот момент не совсем понятен. Точнее - действия с моей стороны ясны, но непонятно, что будет происходить при объединении всех нод в кластер.

---

<div class="post-metadata">

**Author:** ![Evgeny\_Lazarev](https://avatars.discourse-cdn.com/v4/letter/e/d07c76/32.png) [@Evgeny\_Lazarev](https://discuss.elastic.co/u/Evgeny_Lazarev)\
**Post date:** [June 2, 2016, 2:52pm UTC](https://discuss.elastic.co/t/threadpool/51054/24 "2016-06-02T14:52:16Z")

</div>

> [@ei-grad](#):
>
> У тебя действительно одна машина с необходимым объемом записи не справляется? А то с таким конфигом смысла в кластере не много.

Нет. Скорость линейно падает и в какой то момент начинают уже таски Спарка валится по таймауту.

Тут, кстати, есть один интересный вопрос (один из главных, с котором я столкнулся) - почему появляются паузы при индексировании? (на графике индексирования марвела есть паузы в ноль секунд на 10-15 примерно)

---

<div class="post-metadata">

**Author:** ![ei-grad](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ei-grad/32/5775_2.png) [@ei-grad](https://discuss.elastic.co/u/ei-grad)\
**Post date:** [June 3, 2016, 10:01am UTC](https://discuss.elastic.co/t/threadpool/51054/25 "2016-06-03T10:01:01Z")

</div>

> Вот этот момент не совсем понятен. Точнее - действия с моей стороны ясны, но непонятно, что будет происходить при объединении всех нод в кластер.

Нода подключается к мастеру и говорит "смотри у меня тут вот такой индекс валяется, я его подниму?". Вроде ничего плохого.

Кстати, наткнулся тут вот на такую штуку - [http://www.poudro.com/blog/building-an-elasticsearch-index-offline-using-hadoop-pig/](http://www.poudro.com/blog/building-an-elasticsearch-index-offline-using-hadoop-pig/). Это еще больший изврат, но кажется может иметь смысл.

---

<div class="post-metadata">

**Author:** ![ei-grad](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ei-grad/32/5775_2.png) [@ei-grad](https://discuss.elastic.co/u/ei-grad)\
**Post date:** [June 3, 2016, 10:05am UTC](https://discuss.elastic.co/t/threadpool/51054/26 "2016-06-03T10:05:50Z")

</div>

> Это еще больший изврат, но кажется может иметь смысл.

На самом деле, как минимум, написав свой индексатор сможешь понять какие могут быть затыки в индексировании у ES. Не все наверное, но всё равно. Хотя конечно покурить код самого ES было бы правильнее, но это сложно, проще свой индексатор написать 🙂 .

---

<div class="post-metadata">

**Author:** ![ei-grad](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ei-grad/32/5775_2.png) [@ei-grad](https://discuss.elastic.co/u/ei-grad)\
**Post date:** [June 3, 2016, 10:35am UTC](https://discuss.elastic.co/t/threadpool/51054/27 "2016-06-03T10:35:28Z")

</div>

> Тут, кстати, есть один интересный вопрос (один из главных, с котором я столкнулся) - почему появляются паузы при индексировании? (на графике индексирования марвела есть паузы в ноль секунд на 10-15 примерно)

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

В своем кластере вижу как в CPU уходят синхронно по-очереди то эластики, то импортеры.

---

<div class="post-metadata">

**Author:** ![ei-grad](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ei-grad/32/5775_2.png) [@ei-grad](https://discuss.elastic.co/u/ei-grad)\
**Post date:** [June 3, 2016, 6:37pm UTC](https://discuss.elastic.co/t/threadpool/51054/28 "2016-06-03T18:37:55Z")

</div>

Еще в тему извращений, [https://github.com/MyPureCloud/elasticsearch-lambda](https://github.com/MyPureCloud/elasticsearch-lambda) - чуваки заморочились и на голом mapreduce развили вариант загрузки с single-node/single-index per loader (как я выше описывал) до single-shard per loader, только после создания индекса зачем-то (зачем?) отгружают его через snapshot (и как потом шарды из отдельных снэпшотов в индекс склеивать? или снэпшот один и шарды туда через черную магию запихиваюся?).

Тема также обсуждалась в гуглогруппе - [https://groups.google.com/forum/#!topic/elasticsearch/xU5Faf3l5IM](https://groups.google.com/forum/#!topic/elasticsearch/xU5Faf3l5IM), но я там ничего интересного не вижу. Есть ссылка на wonderdog (ruby-шная поделка для обычного bulk load через hadoop, умеет запускать клиентскую ноду, вероятно не работает с es-2.x), и на статью про свежие версии lucene (если я правильно понимаю - в es-2.x это всё уже работает из коробки, но он всё равно не жрет 100% CPU / IO как обещает заголовок статьи, впрочем статью наверно стоило бы прочитать, но сайт лежит).

Вообще, если всерьез такие штуки обсуждать нужно для начала ответить на вопросы:

- Какие проблемы решает Elasticsearch при массовой загрузке данных, с которыми придется столкнуться при создании индекса напрямую через lucene?

- И наоборот, какие проблемы решать не нужно? Можно ли принципиально ускорить процесс построения индексов, если отбросить необходимость обновления этого индекса и поиска по нему в процессе заполнения?

- Сработает ли подход "сгенерировать индекс напрямую через lucene и скормить его файлы ноде ES при запуске"? Какие подводные камни?

Я на них ответить достаточно подробно не могу :-). Так что это всё пока на пустом месте... хотя сделать и посмотреть это тоже вариант.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 1:47pm UTC](https://discuss.elastic.co/t/threadpool/51054/29 "2017-07-06T13:47:47Z")

</div>



[Previous page](https://discuss.elastic.co/t/threadpool/51054.md?page=1)