Elasticsearch and OpenSearch
Search clusters are memory-hungry, disk-sensitive and famous for ending up on the public internet with no authentication.
Never expose it
Start here, because this is how it goes wrong. Unsecured clusters have leaked hundreds of millions of records, and they are found by scanners within minutes.
network.host: 10.0.0.5 — a private address, never
0.0.0.0
Enable the security features, set passwords for the built-in users, and put it behind the firewall as well. If you need to reach the dashboard, do it over WireGuard rather than publishing a port. See connecting your own servers.
Heap: half, and never over 32 GB
Two rules that matter more than anything else:
- Give the JVM half the machine's memory. The other half is for the filesystem cache, which is where Lucene actually lives. Starve that and everything is slow.
- Never exceed about 31 GB of heap. Above that the JVM loses compressed object pointers and you get less usable memory from more RAM.
So on a 128 GB machine, run several nodes of 31 GB rather than one enormous one.
Set -Xms and -Xmx equal, and see
running a JVM application.
Disable swap entirely, or set bootstrap.memory_lock: true. A swapping
search node is worse than a stopped one.
Disks
Local NVMe. Search is random reads, and the whole design assumes the operating system can cache aggressively over fast storage. Network storage for a search cluster is a reliable way to be disappointed — see SAS, SATA and NVMe.
Raise the file descriptor limit (65535) and vm.max_map_count to 262144,
or the node refuses to start.
Shards: fewer than you think
The commonest mistake is over-sharding. Every shard is a Lucene index with its own overhead, and a cluster with thousands of tiny shards spends its life on bookkeeping.
Aim for shards of 10–50 GB. For time-series data, use time-based indices with a rollover policy and delete whole old indices rather than deleting documents — deletion in Lucene is expensive and only reclaims space at merge time.
You cannot change a shard count after creation. Plan it, or plan a reindex.
Three nodes or one
One node is fine for a search index you can rebuild from the source of truth. If you need resilience, use three master-eligible nodes — never two, which cannot establish a quorum and will split.
Set index.number_of_replicas: 1 only when there is somewhere else to
put the replica; a replica on the same node protects against nothing.
Back up with snapshots
Not a file copy of the data directory. Register a repository — an S3-compatible store works well — and use the snapshot API on a schedule. Then do what testing a restore says and actually restore one.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base