OpenSearch and Elasticsearch on dedicated servers: heap, shards, nodes

An OpenSearch or Elasticsearch cluster on dedicated servers needs three nodes for high availability, a JVM heap of no more than half the RAM and under about 31 GB, shards of roughly 10 to 50 GB, and fast local disks. Three 128 GB servers with NVMe or six SSDs each cover a typical log or search cluster.

This guide explains each of those rules, sizes disks with a worked example, matches node roles to servers you can order, and sets out the licensing difference between the two projects in plain terms.

What does an OpenSearch or Elasticsearch cluster need from a dedicated server?

OpenSearch and Elasticsearch share a common origin and the same basic design. Each node is a Java process that stores data in Lucene indices on local disk. An index is split into shards, each shard can have replicas on other nodes, and the cluster spreads them so that losing one machine loses no data.

That design asks for four things from the hardware. Memory, split between the JVM heap and the operating system's file cache. Fast disks, because indexing writes and merges segments all day and searches read them at random. Enough cores to index and search at the same time. And a reliable network between nodes, because replicas and recoveries copy whole shards across it.

Bare metal suits this well. A search node is busy around the clock, so nothing is gained from sharing a host, and steady disk and memory performance makes shard sizing predictable.

How much JVM heap should OpenSearch use?

The long standing rule is the same for both: give the heap at most half of the server's RAM, and keep it below about 31 GB. The first half of the rule leaves memory for the file cache, which Lucene relies on heavily. The second keeps the JVM using compressed object pointers, which stop working just above 31 GB and make every object reference larger. A heap of 32 GB or a little more can hold less than one of 31 GB.

On a 128 GB server that means a 31 GB heap, with the other 97 GB left for the file cache and the operating system. Set the minimum and maximum to the same value so the heap never resizes:

# jvm.options.d/heap.options
-Xms31g
-Xmx31g

# /etc/sysctl.d/99-search.conf
vm.max_map_count = 262144

The vm.max_map_count setting is required by both projects, because Lucene maps index files into memory. Switch swap off, or lock the heap in memory, so a busy node never pages part of its heap out to disk. The startup log reports whether compressed object pointers are in use, so check it after any heap change.

What about servers with more RAM?

Above 64 GB of RAM the heap stays at about 31 GB, and the extra memory goes to the file cache, which still helps: more of the index stays in memory and searches touch the disk less. On a 256 GB server some teams run two nodes instead of one. If you do, set cluster.routing.allocation.same_shard.host to true so a shard and its replica never land on the same machine, and pin each node to one socket on a two socket server, as our guide to NUMA on dual socket servers explains.

How do you size shards and disks?

A common target is 10 to 50 GB per shard. Smaller shards waste heap, because every shard carries overhead whether it holds 1 GB or 40 GB, and thousands of tiny shards slow down the whole cluster. Larger shards take longer to move and recover after a node fails. For logs and time series, roll indices over by size with Index State Management in OpenSearch or Index Lifecycle Management in Elasticsearch, so shards stay inside the range on their own.

A worked example

As an example, take 50 GB of raw logs a day, kept for 30 days, with one replica. Assume the data takes 1.1 times its raw size on disk once indexed. That ratio depends on your mappings and fields, so replace it with a figure measured on your own data.

Step	Calculation	Result
Primary data per day	50 GB × 1.1	55 GB, as 2 primary shards of 27.5 GB
Primary data for 30 days	55 GB × 30	1,650 GB
With one replica	1,650 GB × 2	3,300 GB, about 3.3 TB
Below the 85 percent disk watermark	3.3 TB ÷ 0.85	about 3.9 TB
Per node in a three node cluster	3.9 TB ÷ 3	about 1.3 TB

The watermark matters. By default both projects stop placing new shards on a node above 85 percent disk use, move shards away above 90 percent, and block writes to its indices at 95 percent. A cluster sized to fill its disks stops accepting logs at the worst moment, so plan for the 85 percent line, not for full disks.

NVMe, SSD and RAID

Hot data, the indices that receive writes and most searches, belongs on NVMe. Older indices that are searched now and then can live on SSD at a lower price per terabyte. With replicas on other nodes, many clusters stripe each node's local disks into one volume and let the replicas be the redundancy. RAID 10 costs half the capacity but means a single failed disk does not force a full node recovery.

Why does an OpenSearch cluster need three nodes?

A cluster elects one node to manage its state: the cluster manager in OpenSearch, the master in Elasticsearch. An election needs a majority of the eligible nodes. With two nodes, losing either one leaves no majority, so the cluster cannot safely carry on. With three, any one can fail and the other two still form a majority and keep serving.

Three nodes that each hold data and are eligible to manage the cluster is the usual small production layout. One replica per shard then means every shard exists on two different machines, and the cluster survives the loss of any one server without losing data.

Recovery time and the port

When a node fails, the cluster copies the missing replicas to the others, and the new node has to receive its shards again. In the example a node holds about 1.3 TB. At the full line rate of a 1 Gbps port that is 10,400 seconds, nearly three hours, and real recoveries run slower. A 10 Gbps guaranteed port cuts the line rate figure to about 17 minutes, for €450 a month more per Xeon server or €720 per EPYC server. Ports on every dedicated server are unmetered, so replication and recovery traffic carry no transfer bill.

Order the nodes in the same location so traffic between them stays short, and turn on TLS for the transport layer, since node to node traffic crosses the network like any other.

Which dedicated servers fit each node?

Here are three node layouts for the worked example, priced for a three node cluster. Prices are monthly, exclude VAT and include the 1 Gbps guaranteed unmetered port.

Node	Cores	RAM	Storage per node	Per node	Three nodes
Single EPYC 9254	24	128 GB DDR5 ECC	2 × 1 TB NVMe	€449	€1,347
Dual Xeon E5 2690 v4 + 6 × 1 TB SSD	28	128 GB DDR4 ECC	6 TB SSD raw	€289	€867
Dual Xeon E5 2699 v4 + 6 × 1 TB SSD	44	256 GB DDR4 ECC	6 TB SSD raw	€359	€1,077

The Single EPYC 9254 is the fast hot node: Zen 4 cores, DDR5 and NVMe, and 2 TB of raw NVMe covers the 1.3 TB per node of the example when striped. It is built to order, with a delivery estimate of about 14 days. Our EPYC 9254 guide covers the processor.

The Dual Xeon E5 2690 v4 with six SSDs is the economical option, with plenty of room for longer retention. The Dual Xeon E5 2699 v4 adds cores and 256 GB, useful for heavy aggregations or two nodes per machine. The Xeons are delivered in about 45 minutes.

Hot and warm tiers

For long retention, split the roles. Keep recent indices on EPYC nodes with NVMe and move older ones to warm nodes with large SSD arrays, such as the Dual Xeon E5 2699 v4 with 6 × 4 TB SSD for €659 a month per node. Index lifecycle policies move the data between tiers automatically.

OpenSearch or Elasticsearch: what is the licensing difference?

The technical choice is mostly about features, plugins and tooling, and both run the same way on our servers. Licensing is where they differ, and it is worth knowing before you commit.

• Elasticsearch moved away from the Apache 2.0 licence in 2021 to Elastic's own licences. In 2024 Elastic added the AGPL as a further option for the source code. Some features sit in paid subscription tiers.
• OpenSearch was forked from Elasticsearch 7.10 in 2021 and is licensed under Apache 2.0. Since 2024 it has been governed by the OpenSearch Software Foundation, part of the Linux Foundation.

Neither licence stops you running the software on your own dedicated server for your own business. They matter more if you plan to offer search as a service to others or to modify and distribute the code, so read the licence text for your case. The two projects have diverged since the fork, so moving between them later means testing your mappings, queries and clients, not just swapping binaries.

Questions people ask

Can I run OpenSearch on a single dedicated server?

Yes. Set discovery.type to single-node and use zero replicas, since there is nowhere else to place them. It works well for development, internal search or logs you can afford to lose. For anything that must stay up, plan three nodes and take snapshots to separate storage either way.

How much RAM does an OpenSearch node need?

Enough for a heap of up to about 31 GB plus a file cache that holds your hot indices. A 128 GB server gives a 31 GB heap and about 97 GB of file cache, which suits most nodes. Search heavy clusters with large hot indices gain from 256 GB.

Is ClickHouse a better fit for logs?

For logs that are mostly aggregated in dashboards and rarely searched by full text, it can be. A columnar database compresses logs hard and answers counts and percentiles quickly, as our ClickHouse server guide explains. For free text search, relevance ranking and log exploration, OpenSearch and Elasticsearch remain the natural tools.

Which ports should be open?

The REST API listens on 9200 and node to node transport on 9300. Allow 9300 only between your nodes, allow 9200 only from your applications, dashboards and log shippers, and never expose either to the whole internet. Elasticsearch 8 turns security on by default, and OpenSearch ships a security plugin that should stay enabled.

Build the cluster

Measure your daily volume and on disk ratio, run the worked example with your own numbers, and pick a node from the table. Compare every configuration on our dedicated server range, and order the three nodes in one location so they replicate over a short path.