Why is multiple instances per node not recommended?

Elastic Stack Elasticsearch
1

I'm doing consultant work for a large government organization that need
some guidelines for how to set up ElasticSearch or Solr for their projects.

One topic that has surfaced several times is the validity in running
several ES instances per node. The use-case is that several smaller
projects (about 10-15)
need access to a search cluster with replication and redundancy, so I'm
guessing that a cluster size of 3-4 nodes will be typical. The argument for
running several instances per node vs having multiple indices per instance
is that each project gets more "control" over the environment during events
such as full
cluster restarts or version upgrades.

However, I have read that the ES team does not recommend running multiple
instances per node unless you have tons of memory (to preserve compressed
oops).
It would be very helpful to know the reasoning behind this, so why is
running multiple instances not recommended?

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

2

Basically because of IO.
Each node could potentially being a noisy neighbor.

Because of HEAP as well. Instead of needing 8 Gb HEAP per project (it's a random number here - don't take it as a mandatory value!), may be sharing 16 Gb HEAP with 10 projects will be fine?

My 0.05 cents.

--
David Pilato | Technical Advocate | Elasticsearch.com
@dadoonet | @elasticsearchfr

Le 26 novembre 2013 at 12:26:12, Gunnar Gauslaa Bergem (gauslaabergem@yahoo.no) a écrit:

I'm doing consultant work for a large government organization that need some guidelines for how to set up ElasticSearch or Solr for their projects.

One topic that has surfaced several times is the validity in running several ES instances per node. The use-case is that several smaller projects (about 10-15)
need access to a search cluster with replication and redundancy, so I'm guessing that a cluster size of 3-4 nodes will be typical. The argument for
running several instances per node vs having multiple indices per instance is that each project gets more "control" over the environment during events such as full
cluster restarts or version upgrades.

However, I have read that the ES team does not recommend running multiple instances per node unless you have tons of memory (to preserve compressed oops).
It would be very helpful to know the reasoning behind this, so why is running multiple instances not recommended?

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

3

You should not start many ES nodes on a single server because

  • each JVM adds significant overhead to CPU and OS memory management

  • a modern Java 7 JVM scales well even on the largest multi core machine

  • a single ES node can scale over all available threads and heap mem of a
    single JVM

Many users run ES not on bare metal, but on a VM. Running multiple JVMs on
a single VM adds even more overhead.

Jörg

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEvAgGgA-fdB4Agsvk96z%2BkF2aseY9NpSGCejbz1zCadw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.