# ES 5.6 inmemory-node recovers faster than standalone ES server

**URL:** <https://discuss.elastic.co/t/es-5-6-inmemory-node-recovers-faster-than-standalone-es-server/211992>\
**Category:** Elasticsearch\
**Created:** [December 16, 2019, 11:28am UTC](https://discuss.elastic.co/t/es-5-6-inmemory-node-recovers-faster-than-standalone-es-server/211992 "2019-12-16T11:28:11Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![kayshu](https://avatars.discourse-cdn.com/v4/letter/k/b782af/32.png) [@kayshu](https://discuss.elastic.co/u/kayshu)\
**Post date:** [December 16, 2019, 11:28am UTC](https://discuss.elastic.co/t/es-5-6-inmemory-node-recovers-faster-than-standalone-es-server/211992/1 "2019-12-16T11:28:11Z")

</div>

Hi,

During some testing with a ES5.6 with about 4GB of data (3k shards), with an **inmemory-node** we are getting really fast shard recovery during startup (5 times faster than standalone ES server).  
A standalone ES server takes about 20 minutes on my machine to recover completely (i.e all shards change from unassigned to started state) whereas a in-memory node recovers and starts all the shard in just 4 minutes. Is this expected behaviour ? what could be the cause of this.

---

<div class="post-metadata">

**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\
**Post date:** [December 16, 2019, 5:08pm UTC](https://discuss.elastic.co/t/es-5-6-inmemory-node-recovers-faster-than-standalone-es-server/211992/2 "2019-12-16T17:08:47Z")

</div>

can you explain what an in-memory node is? Elasticsearch does not have such a feature, as all data is persisted to disk.

That said, 3k shards for a single node are too much and you should reduce. Also, in order to speed up recoveries on node start up, looking at synced flush might make some sense.

Lastly, you should consider to upgrade to one of the more recent elasticsearch versions, coming with tons of bugfixes and performance improvements.`

---

<div class="post-metadata">

**Author:** ![kayshu](https://avatars.discourse-cdn.com/v4/letter/k/b782af/32.png) [@kayshu](https://discuss.elastic.co/u/kayshu)\
**Post date:** [December 17, 2019, 6:30am UTC](https://discuss.elastic.co/t/es-5-6-inmemory-node-recovers-faster-than-standalone-es-server/211992/3 "2019-12-17T06:30:42Z")

</div>

Sorry for not explaining it well, by an **in-memory** node, i meant an embedded node. i.e creating the node directly using **org.elasticsearch.node.Node**

Something like this

```
    Settings settings = Settings.builder()
                        .put("path.home", homePath)
                        .build();
    node = new Node(settings);
    node.start();

```

also the **3k shards** is just for testing. (but will number of shards affect the cluster performance even if data size is less ?)

---

<div class="post-metadata">

**Author:** ![kayshu](https://avatars.discourse-cdn.com/v4/letter/k/b782af/32.png) [@kayshu](https://discuss.elastic.co/u/kayshu)\
**Post date:** [December 19, 2019, 10:39am UTC](https://discuss.elastic.co/t/es-5-6-inmemory-node-recovers-faster-than-standalone-es-server/211992/4 "2019-12-19T10:39:30Z")

</div>

@spinscale

So after much digging, it looks like the slow recovery was because of the Elasticsearch's Security Manager. Since the Embedded node was started directly and had no interference from the security manager, hence it recovered faster.  
I know that the feature to disable the security manager has been removed. But what are the disadvantages of disabling the SecurityManager?

---

<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:** [January 16, 2020, 10:39am UTC](https://discuss.elastic.co/t/es-5-6-inmemory-node-recovers-faster-than-standalone-es-server/211992/5 "2020-01-16T10:39:32Z")

</div>

Closed on January 16, 2020, 10:39am UTC

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.