Да, у нас на каждой ноде 128 Гб RAM, и под Heap отдано 96 Гб.
Но после миграции по версиям с 6.0 и до 7.4 потребление памяти уменьшилось
Сейчас можно и уменьшить раза в 2
Но меньше 30 боюсь не удастся - не запустится, настолько много шард
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [October 21, 2019, 7:50pm UTC](https://discuss.elastic.co/t/7-3-2/201228/42 "2019-10-21T19:50:52Z")
> [@Denis\_Lamanov](#):
>
> Но меньше 30 боюсь не удастся - не запустится, настолько много шард
Да, lucene использует по 12-13 Гб на свои нужды, fielddata - маленький, надо уменьшать осторожно. Но уменьшать надо и если будет не хватать - то надо добавлять узлы.
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 21, 2019, 8:03pm UTC](https://discuss.elastic.co/t/7-3-2/201228/43 "2019-10-21T20:03:03Z")
А запускать на одной ноде несколько сервисов Эластика насколько я понял уже не рекомендуется?
До скольки для начала можно уменьшить?
Рекомендуете убрать мастер роль со всех дата нод?
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [October 21, 2019, 8:17pm UTC](https://discuss.elastic.co/t/7-3-2/201228/44 "2019-10-21T20:17:05Z")
> [@Denis\_Lamanov](#):
>
> А запускать на одной ноде несколько сервисов Эластика насколько я понял уже не рекомендуется?
Это все-равно лучше, чем запускать узлы с 60Гб памяти.
> [@Denis\_Lamanov](#):
>
> До скольки для начала можно уменьшить?
Затрудняюсь тут что-то сказать. У меня опыта работы с узлами с такими большими хипами - нет.
> [@Denis\_Lamanov](#):
>
> Рекомендуете убрать мастер роль со всех дата нод?
В принципе - да, но у вас не так много узлов в данный момент. Если вы со всех узлов данных эту роль уберете, то кто будет управлять кластером?
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 21, 2019, 8:25pm UTC](https://discuss.elastic.co/t/7-3-2/201228/45 "2019-10-21T20:25:30Z")
> [@Igor\_Motov](#):
>
> В принципе - да, но у вас не так много узлов в данный момент. Если вы со всех узлов данных эту роль уберете, то кто будет управлять кластером?
У нас есть несколько виртуалок. Думаю 3 ноды можно поднять для управления
Насколько я понял сейчас все тормоза из-за большего времени сборки мусора?
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 21, 2019, 8:36pm UTC](https://discuss.elastic.co/t/7-3-2/201228/46 "2019-10-21T20:36:35Z")
На всякий случай наш конфиг:
http.max\_content\_length: 256mb
node.master: true
node.data: true
index.codec: best\_compression
thread\_pool.write.queue\_size: 5000
indices.memory.index\_buffer\_size: 20%
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 22, 2019, 6:07am UTC](https://discuss.elastic.co/t/7-3-2/201228/47 "2019-10-22T06:07:39Z")
Решили попробовать поднять на каждом физическом сервере по 3 ноды, т.е. будет 7 \* 3 = 21 нода
Каждой ноде дать 29 Гб RAM, т.е. 40 останется на файловый кэш
Как в таком случае разбивать индекксы на шарды: на каждый индекс 21 шарду?
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 22, 2019, 12:03pm UTC](https://discuss.elastic.co/t/7-3-2/201228/48 "2019-10-22T12:03:53Z")
Логи с мастера и ещё одной ноді за сегодня:
> **[Production-node02.log](https://drive.google.com/file/d/1ODO2_l-ViTyIVM4WBcBf4XRCkPT6fSUa/view?usp=drive_open)**
>
> Google Drive file.
> **[Production-node06.log](https://drive.google.com/file/d/1mTNVLhaFEuYNfWuGxoFx9qoojFv1OLgo/view?usp=drive_open)**
>
> Google Drive file.
Утром ещё убрали четверть нагрузки с кластера. Таймауты получения статистики всё равно остались.
Самое интересное, что до этого с большей нагрузкой на 6.8, 7.3 такого никогда не было
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [October 22, 2019, 3:23pm UTC](https://discuss.elastic.co/t/7-3-2/201228/49 "2019-10-22T15:23:13Z")
```auto
http.max_content_length: 256mb
```
Это у Вас такие большие сообщения?
```auto
thread_pool.write.queue_size: 5000
```
А это зачем?
> [@Denis\_Lamanov](#):
>
> Насколько я понял сейчас все тормоза из-за большего времени сборки мусора?
Я думаю, это одна из причин. У меня было много случаев, когда после того, как проблема с GC исправлялась, все остальное вставало на свои места. Но бывает, что это проблему полностью не решает, но позволяет выявить другие проблемы, которых сейчас не видно из-за этих непрерывных пауз.
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 22, 2019, 3:35pm UTC](https://discuss.elastic.co/t/7-3-2/201228/50 "2019-10-22T15:35:42Z")
> [@Igor\_Motov](#):
>
> Это у Вас такие большие сообщения?
Мы пишем батчами. Бывают больше сотни Мб. После оптимизации не знаю доходит ли до 200 Мб
> [@Igor\_Motov](#):
>
> А это зачем?
Много активных индексов в которые пишется и очереди в 200 не хватало, были реджекты
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [October 22, 2019, 3:51pm UTC](https://discuss.elastic.co/t/7-3-2/201228/51 "2019-10-22T15:51:05Z")
> [@Denis\_Lamanov](#):
>
> Мы пишем батчами. Бывают больше сотни Мб. После оптимизации не знаю доходит ли до 200 Мб
Батчи можно было бы и уменьшить.
> [@Denis\_Lamanov](#):
>
> Много активных индексов в которые пишется и очереди в 200 не хватало, были реджекты
Реджекты надо обрабатывать на клиенте, или добавить очередь какую-нибудь, а не сваливать эту работу на elasticsearch.
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 22, 2019, 7:28pm UTC](https://discuss.elastic.co/t/7-3-2/201228/52 "2019-10-22T19:28:25Z")
> [@Igor\_Motov](#):
>
> Реджекты надо обрабатывать на клиенте, или добавить очередь какую-нибудь, а не сваливать эту работу на elasticsearch.
Сейчас сделали ElasticSearchWriterPool который регулирует максимальную параллельность записи и динамически регулирует батчи
---
### Author:  [@andrx](https://discuss.elastic.co/u/andrx)
#### Post date: [October 23, 2019, 3:05am UTC](https://discuss.elastic.co/t/7-3-2/201228/53 "2019-10-23T03:05:15Z")
У нас похожий сценарий и бывает клиенты загружают очень много данных, правда никогда не переваливали дефолтные значения. Опытным путем выбраны настройки для параллельности и батчи для bulks + circuit breaker/retry логика, чтобы не перегружать кластер. Я хотел спросить, интересно, как устроен _ElasticSearchWriterPool_, т.е. от чего он отталкивается и как он работает чтобы определить эти параметры?
Раньше тоже были проблемы с _queue\_size_, но теперь таких проблем нет. Остались только [проблемы с переездом на 7.4.0](https://discuss.elastic.co/t/es-6-8-vs-7-4-memory-issues/202849) (пока никто не помог). При downgrade на 7.3.2 - все хорошо.
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 24, 2019, 12:12pm UTC](https://discuss.elastic.co/t/7-3-2/201228/54 "2019-10-24T12:12:44Z")
Мне интересно как объяснить этот случай
Подняли тестовый кластер. Минимальная нагрузка.
Периодически одна нода(координатор) отваливается. В большинстве случаев она возвращается, но бывает, что начинаются долгие перевыборы. Она не может присоединитсья к кластеру. Ни нагрузки, ни проблем с сетью там нет.
Вот лог с координатора
> **[node-master.log](https://drive.google.com/file/d/1gYE4_6TDnGIdK_nTJv0mVgLAD9SpnUcQ/view?usp=drive_open)**
>
> Google Drive file.
Почему нода так долго не могла присоединиться к кластеру?
Есть ещё логи похожие. Чуть позже приложу. В логах GC даже нет
Лог с node-00, которая была выбрана в это время мастером и отключила node-master считая, что начался лаг
> **[node00.log](https://drive.google.com/file/d/1sAtiDi5w6LScJgr_qFt86gKD5GnZUCV-/view?usp=drive_open)**
>
> Google Drive file.
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 24, 2019, 12:36pm UTC](https://discuss.elastic.co/t/7-3-2/201228/55 "2019-10-24T12:36:43Z")
node-00 утверждает, что node-master целых 3 минуты делала publication of cluster state version
Но там мало шард, cluster state передаётся как диффы. Это очень странно
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [October 24, 2019, 1:32pm UTC](https://discuss.elastic.co/t/7-3-2/201228/56 "2019-10-24T13:32:34Z")
Проблема, может быть в elasticsearch, или в том, как ваша сеть или виртуалки работают. Если бы проблема была в elasticsearch, то мы бы видели что-то в [github](https://github.com/elastic/elasticsearch/issues?q=is%3Aissue+label%3A%22%3ADistributed%2FCluster+Coordination%22+is%3Aopen).
Чтобы разобраться, что там конкретно не работает, было бы хорошо посмотреть на логи на более низком уровне: `logger.org.elasticsearch.cluster.service:TRACE` и `logger.org.elasticsearch.gateway.MetaStateService:TRACE`.
Кстати, время в логах отличается на несколько часов. Это так машины настроены, или это логи выбраны в разное время?
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 24, 2019, 1:51pm UTC](https://discuss.elastic.co/t/7-3-2/201228/57 "2019-10-24T13:51:42Z")
TRACE добавляю.
На дата нодах выставлен UTC, а на координаторе текущий пояс. Тоже исправляю.
Жду следующего такого случаю и пришлю логи
Спасибо
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 25, 2019, 1:31pm UTC](https://discuss.elastic.co/t/7-3-2/201228/58 "2019-10-25T13:31:04Z")
По поводу ошибки обновления cluster:monitor/nodes/stats которая возникает на продакшене
Словили её и на тесте. В это время ни на node-master ни на node-00 не было нагрузки на процессор или диск и с сетью всё было хорошо.
Кстати, node-master периодически вылетает из кластера, но за сотые доли секунды переподключается. Якобы это TransportException и разрывается tcp коннекшен. С этим ещё разбираемся.
Лог с node-00:
> **[node-00.log](https://drive.google.com/file/d/11ZV6RotRadvtghmoHqHEqDc05nMXEMwC/view?usp=drive_open)**
>
> Google Drive file.
Лог с node-master:
> **[node-master.log](https://drive.google.com/file/d/12dEEScGPBMHTCmnKLXuN7VkWnDWfFUSo/view?usp=drive_open)**
>
> Google Drive file.
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [October 25, 2019, 3:41pm UTC](https://discuss.elastic.co/t/7-3-2/201228/59 "2019-10-25T15:41:18Z")
Может, у вас там какое-нибудь "умное" сетевое оборудование умничает и обрывает соединения? Как у вас сеть настроена? Еще не очень понятно, почему логи обрезаны. Например:
```auto
[2019-10-25T15:36:08,734][DEBUG][o.e.c.s.ClusterApplierService] [node-master] processing [ApplyCommitRequest{term=79, version=22649, sourceNode={node-00}{cMIMAQ2cQBKx-0W0VqGzrg}{X9k02oS0SRKNhqdtvPeI8g}{192.168.11.3
```
Строка заканчивается на самом интересном месте. Пока что, дело ясное, что дело темное. Было бы полезно еще `org.elasticsearch.cluster.coordination: TRACE` добавить к следующему сбою и логи не резать.
---
### Author:  [@Denis\_Lamanov](https://discuss.elastic.co/u/Denis_Lamanov)
#### Post date: [October 25, 2019, 3:58pm UTC](https://discuss.elastic.co/t/7-3-2/201228/60 "2019-10-25T15:58:00Z")
Да, извиняюсь, вырезал всю мета-информацию об индексах и зацепил
В той строчке:
`[2019-10-25T15:36:08,734][DEBUG][o.e.c.s.ClusterApplierService] [node-master] processing [ApplyCommitRequest{term=79, version=22649, sourceNode={node-00}{cMIMAQ2cQBKx-0W0VqGzrg}{X9k02oS0SRKNhqdtvPeI8g}{192.168.11.39}{192.168.11.39:9300}{dim}}]: took [0s] done applying updated cluster state (version: 22649, uuid: glYQaVfWRFKOEKrkg02zng)`
Добавил в конфиг `logger.org.elasticsearch.cluster.coordination: TRACE`, жду логов)
Спасибо
[Previous page](https://discuss.elastic.co/t/7-3-2/201228.md?page=2)
[Next page](https://discuss.elastic.co/t/7-3-2/201228.md?page=4)