# Is it normal to have 6 ES nodes with 100GB heap size each on 6x 192GB RAM servers?
**URL:** https://discuss.elastic.co/t/is-it-normal-to-have-6-es-nodes-with-100gb-heap-size-each-on-6x-192gb-ram-servers/41677
**Category:** Elasticsearch
**Created:** [February 13, 2016, 2:06am UTC](https://discuss.elastic.co/t/is-it-normal-to-have-6-es-nodes-with-100gb-heap-size-each-on-6x-192gb-ram-servers/41677 "2016-02-13T02:06:35Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@anhlqn](https://discuss.elastic.co/u/anhlqn)
#### Post date: [February 13, 2016, 2:06am UTC](https://discuss.elastic.co/t/is-it-normal-to-have-6-es-nodes-with-100gb-heap-size-each-on-6x-192gb-ram-servers/41677/1 "2016-02-13T02:06:35Z")
Our production ES cluster has 10 nodes in which:
6 x 192 GB RAM for hot indexes (data within 2 weeks)
2 x 32GB RAM for cold indexes (data older than 2 weeks)
2 x 32 GB RAM client nodes/master only nodes.
- Running ES 1.7.1
- Application logs are stored into daily indexes with around 70GB each index, high EPS I guess.
- Each node with 192GB RAM has an ES instance with heap size of 90GB and `index.store.type: memory`. Hot indexes are stored in RAM only, cold indexes will be moved to 2 cold ES nodes.
- Data on ES are solely for full text searching, and each message is relatively large.
Some of my questions:
1. Is it a good setup/config to have ES node with 90GB of ES\_HEAP\_SIZE even when using `index.store.type: memory`?
2. Would it be better to switch to SSD and run more ES instances on 6x 192GB RAM servers with ES\_HEAP\_SIZE 31G?
3. Any suggestion on setting up a cluster that indexes around 70 to 100GB per day for 2 weeks and provides fast searching/querying?
I keep seeing recommendations that we should keep ES\_HEAP\_SIZE \<= 30.5G, how about my case with 90G? Unfortunately, I have not had enough info on the cluster.
Thanks,
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [February 13, 2016, 11:14pm UTC](https://discuss.elastic.co/t/is-it-normal-to-have-6-es-nodes-with-100gb-heap-size-each-on-6x-192gb-ram-servers/41677/2 "2016-02-13T23:14:58Z")
> [@anhlqn](#):
>
> - Is it a good setup/config to have ES node with 90GB of ES\_HEAP\_SIZE even when using index.store.type: memory?
No.
> [@anhlqn](#):
>
> - Would it be better to switch to SSD and run more ES instances on 6x 192GB RAM servers with ES\_HEAP\_SIZE 31G?
No, see your later comment about 30.5GB, we state that for a reason.
---
### Author:  [@anhlqn](https://discuss.elastic.co/u/anhlqn)
#### Post date: [February 14, 2016, 1:15am UTC](https://discuss.elastic.co/t/is-it-normal-to-have-6-es-nodes-with-100gb-heap-size-each-on-6x-192gb-ram-servers/41677/3 "2016-02-14T01:15:38Z")
> [@anhlqn](#):
>
> 1. Any suggestion on setting up a cluster that indexes around 70 to 100GB per day for 2 weeks and provides fast searching/querying?
How about this one?
---
### Author:  [@jasontedor](https://discuss.elastic.co/u/jasontedor)
#### Post date: [February 14, 2016, 5:06am UTC](https://discuss.elastic.co/t/is-it-normal-to-have-6-es-nodes-with-100gb-heap-size-each-on-6x-192gb-ram-servers/41677/4 "2016-02-14T05:06:00Z")
> [@anhlqn](#):
>
> I keep seeing recommendations that we should keep ES\_HEAP\_SIZE \<= 30.5G
This recommendation was useful on JDK 7 but as long as you're on JDK 8, you can get very close to the 32GB boundary and not exceed the limit for compressed oops (for example, 31900m _should_ be fine). In Elasticsearch 2.2.0, we [now print on startup](https://github.com/elastic/elasticsearch/pull/15489) whether or not you've crossed the threshold.
However, do note that your goal should be to _minimize_ the size of the heap, not maximize it.
---
### Author:  [@anhlqn](https://discuss.elastic.co/u/anhlqn)
#### Post date: [February 14, 2016, 5:47am UTC](https://discuss.elastic.co/t/is-it-normal-to-have-6-es-nodes-with-100gb-heap-size-each-on-6x-192gb-ram-servers/41677/5 "2016-02-14T05:47:22Z")
`index.store.type: memory` is no longer supported since ES 2.0?
I'm on JRE 8 now. Is there any difference running ES with JRE vs. JDK?
---
### Author:  [@jasontedor](https://discuss.elastic.co/u/jasontedor)
#### Post date: [February 14, 2016, 6:10pm UTC](https://discuss.elastic.co/t/is-it-normal-to-have-6-es-nodes-with-100gb-heap-size-each-on-6x-192gb-ram-servers/41677/6 "2016-02-14T18:10:39Z")
> [@anhlqn](#):
>
> index.store.type: memory is no longer supported since ES 2.0?
Correct, it is [removed](https://github.com/elastic/elasticsearch/commit/0fcb4665555b589a1c0ce1b7c3f2a4ea071f53da#diff-030d082b410d749d8a5efa156e13c2e0).
> [@anhlqn](#):
>
> I'm on JRE 8 now. Is there any difference running ES with JRE vs. JDK?
There's no difference from a runtime perspective, but the JDK comes with tools that are occasionally useful for debugging.
---
### Author:  [@anhlqn](https://discuss.elastic.co/u/anhlqn)
#### Post date: [February 14, 2016, 6:32pm UTC](https://discuss.elastic.co/t/is-it-normal-to-have-6-es-nodes-with-100gb-heap-size-each-on-6x-192gb-ram-servers/41677/7 "2016-02-14T18:32:59Z")
We are going to have an ES cluster which holds a daily index of 60 to 100 GB and keep daily indices for at least two weeks. ES receives application logs from 70+ servers and serves full text searching. Do you have any recommendation on the number of nodes and configurations?
We also have another cluster with same amount of data but is primarily for aggregation in Kibana. Any suggestion?
---
### Author:  [@jasontedor](https://discuss.elastic.co/u/jasontedor)
#### Post date: [February 15, 2016, 2:25am UTC](https://discuss.elastic.co/t/is-it-normal-to-have-6-es-nodes-with-100gb-heap-size-each-on-6x-192gb-ram-servers/41677/8 "2016-02-15T02:25:23Z")
> [@anhlqn](#):
>
> Do you have any recommendation on the number of nodes and configurations?
The community here is very happy to answer very targeted questions, but that question is far too broad (and lacks specific requirements).
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 5, 2017, 11:16pm UTC](https://discuss.elastic.co/t/is-it-normal-to-have-6-es-nodes-with-100gb-heap-size-each-on-6x-192gb-ram-servers/41677/9 "2017-07-05T23:16:31Z")