$ guides / elasticsearch / how-elasticsearch-works-in-production ▌

Operations Guides

How Elasticsearch actually works in production: a mental model for operators

Elasticsearch is a distributed search and analytics engine built on Apache Lucene. Every node runs interacting subsystems that compete for the same resources. If you treat it as a black box that stores JSON, you will miss the failure modes that kill clusters at 3 a.m. The interactions between subsystems determine whether a cluster survives a traffic spike or collapses into a heap-pressure death spiral.

This guide covers why a node is removed from the cluster, why search latency is pinned to the slowest shard, why more heap can degrade search performance, and why green cluster health does not mean you are safe.

The cluster coordination layer

One node is elected master via the Zen2 consensus protocol introduced in Elasticsearch 7.0. The master maintains the cluster state, a data structure that describes every index, shard, mapping, alias, pipeline, and node. On every change, the master serializes and publishes this state to all nodes.

The master also handles shard allocation, index creation and deletion, and node membership. A slow or overwhelmed master cascades to every operation in the cluster. Fault detection uses follower and leader checks. The defaults are a 10 second timeout, 1 second interval, and 3 retries before node removal. A hard TCP disconnect triggers immediate removal.

In 7.x and later, the voting configuration auto-manages quorum. If you permanently remove master-eligible nodes, exclude them first via POST /_cluster/voting_config_exclusions. If you shut down half or more master-eligible nodes simultaneously without exclusions, the cluster can lose quorum and become unable to elect a master.

Three master-eligible nodes is the recommended minimum. Losing two of three leaves the cluster unavailable rather than risk split-brain. Dedicated master nodes are strongly recommended for production: their resource usage should normally be low, and CPU or heap spikes on a master indicate cluster state management problems, not traffic load.

The shard as a Lucene index

Every Elasticsearch index is divided into primary shards and replica shards. The primary shard count is fixed at index creation. Each shard is a self-contained Lucene index. This is the fundamental unit of work distribution, data isolation, and failure domain.

The coordinating node routes documents to the correct primary shard using a hash of the _id. Shard placement is governed by the allocator, which considers default disk watermarks (low 85%, high 90%, flood stage 95%), allocation filters, awareness attributes, and rebalancing thresholds.

Because each shard is a full Lucene index, it carries fixed overhead: segment metadata per field, thread contexts, and buffers. Thousands of shards per node balloon the cluster state and heap usage. Shard overallocation is one of the most common root causes of master instability and heap pressure. The default cluster.max_shards_per_node limit is 1000 in 7.x and later, but running near that limit is already dangerous.

How it works: the write and read paths

flowchart LR
    C[Coordinating node]
    M[Master node]
    P[Primary shard]
    R[Replica shards]
    T[Translog]
    S[Lucene segment]
    D[Disk / OS page cache]

    M -->|publishes cluster state| C
    M -->|publishes cluster state| P
    M -->|publishes cluster state| R
    C -->|index: route by _id hash| P
    P -->|write-ahead| T
    P -->|buffer then refresh| S
    S -->|flush and merge| D
    P -->|replicate operation| R
    C -->|search: query phase| P
    C -->|search: query phase| R
    P -->|return doc IDs| C
    R -->|return doc IDs| C
    C -->|fetch: gather _source| P
    C -->|fetch: gather _source| R

The write path

When a document arrives, the coordinating node routes it to the primary shard. The primary validates the write and appends it to the translog, a write-ahead log on disk. The document then enters an in-memory buffer managed by Lucene’s IndexWriter.

A refresh (default: every second) converts the buffer into a new Lucene segment. The segment is searchable but not yet independently durable; the translog still protects it. A flush writes a Lucene commit point to disk and truncates the translog. After flush, segments are durable without the translog. Background merge operations combine small segments into larger ones, reclaiming space from deleted documents and improving search performance.

The primary replicates the operation to in-sync replicas. Once the required number of shards (configured by wait_for_active_shards) have written to their translogs, the primary acknowledges success to the client. Replicas redo the same indexing work. There is no segment sharing between primary and replica.

Index success means the write is in the translog on the primary and required replicas. It does not mean the document is immediately searchable. This distinction matters during recovery and when reasoning about durability windows.

The read path

Search uses a two-phase scatter-gather. In the query phase, the coordinating node broadcasts the query to one copy (primary or replica) of every relevant shard. Each shard executes the query locally and returns document IDs plus sort values. The coordinator merges partial results to determine the global top-N.

In the fetch phase, the coordinator requests the actual _source documents for those IDs from the relevant shards. Pure aggregations skip the fetch phase; the coordinator merges per-shard aggregation results directly. If the query also requests hits (size > 0), the coordinator performs a fetch phase for those documents.

The slowest shard determines overall latency. If one shard is cold, overloaded, or recovering, every search that touches it waits. This is why oversharded clusters and hot-spotted nodes are so damaging to read performance.

JVM, thread pools, and circuit breakers

Elasticsearch runs on the JVM with a hard heap ceiling. Stay at or below 26 GB to remain within compressed ordinary object pointers (compressed OOPs). The young generation holds short-lived objects like query contexts; the old generation holds long-lived structures like field data, caches, and segment metadata.

Stop-the-world GC pauses are the direct cause of many node removals. If an old-generation pause exceeds the fault-detection timeout (10 seconds by default), the master removes the node, and shard reallocation begins. That reallocation increases pressure on remaining nodes and can trigger a cascading failure. G1GC is the default collector in Elasticsearch 8.0 and later; in 7.x it is the default only on JDK 14 and newer.

Thread pools isolate operation types: write, search, get, analyze, management, refresh, flush, force_merge, snapshot, generic, listener, cluster_coordination, system_read, and system_write. Each pool has a bounded queue. When the queue fills, the pool rejects requests. Write rejections return HTTP 429. Search rejections fail the query. These rejections are one of the most operationally important signals in the system.

Circuit breakers estimate whether an operation will cause an OutOfMemoryError and reject it preemptively. The defaults are 95% of heap for the parent breaker (with real memory accounting), 40% for fielddata, 60% for requests, and 100% for in-flight requests. A tripped breaker returns HTTP 429. Raising limits instead of fixing root causes risks OOM.

The OS page cache and memory layout

Lucene segments are immutable and served via memory-mapped files. The OS page cache holds segment data off-heap. Elasticsearch relies on the kernel page cache for segment file access rather than caching data in the JVM heap.

Assigning too much memory to the JVM heap leaves no room for the page cache, which degrades search performance. Allocate roughly 50% of system RAM to Elasticsearch heap, up to the compressed OOPs limit, and leave the rest for the OS. Setting index.codec: best_compression trades CPU for a smaller on-disk footprint, which increases the fraction of the index that fits in the page cache.

Doc values are the default for most field types since Elasticsearch 5.x. They shift field data from heap to the filesystem cache. Fielddata caching on analyzed text fields is a common source of heap exhaustion and should be avoided.

Where this model shows up in production

The interactions between these subsystems produce characteristic failure archetypes.

Heap pressure death spiral. Too much data in heap, whether from fielddata, large aggregations, excessive segment metadata, or a bloated cluster state, triggers frequent old-generation GC. Long stop-the-world pauses cause the master to remove the node. Shard reallocation increases heap pressure on the remaining nodes, creating a cascade.

Shard overallocation. Thousands of shards per node create fixed overhead in segment metadata, thread contexts, and cluster state. The master struggles to manage the bloated state, and queries fan out to too many shards.

Disk watermark cascade. A node crosses the high watermark (90%). The allocator relocates shards to other nodes, which also approach their watermarks. Relocations fail, and if any node hits flood stage (95%), its indices are set to index.blocks.read_only_allow_delete. Writes stop. In 7.x and 8.x, the block is automatically removed when disk drops below the high watermark, but only if space is actually freed.

Mapping explosion. Dynamic mapping on unstructured data creates a new field for every unique key. Mappings with tens of thousands of fields inflate the cluster state, grow heap usage on every node, and destabilize the master. Setting index.mapping.total_fields.limit caps this growth.

Merge storms and segment explosion. Bulk indexing creates many small segments. If the merge policy falls behind, search performance degrades, file descriptors grow, and heap usage rises from segment metadata. Force-merge read-only time-series indices to a single segment. Warning: force-merge is I/O intensive and will spike CPU and disk usage until it finishes.

Coordinating node overload. A search that hits many shards forces the coordinating node to merge large result sets. High-cardinality aggregations or deep pagination can spike heap and CPU on the coordinator, tripping circuit breakers even when data nodes are healthy.

Hot-node bottleneck. Uneven shard distribution or time-based index hot-spotting concentrates load on one or two nodes while others idle. This appears as asymmetric CPU, I/O, or thread pool utilization.

Common misuses and dangerous assumptions

Treating green cluster health as sufficient. Green means all shards are assigned. It does not mean the cluster has headroom. A green cluster can be one long GC pause away from a cascade. Monitor heap, disk, and thread pools independently of cluster health.

Adding more heap without regard for the page cache. More JVM heap starves the OS page cache, which increases disk I/O and search latency. The ceiling is not a target; staying well below the compressed OOPs threshold is usually better than maxing out heap.

Ignoring the master node. Teams monitor data nodes obsessively and ignore masters until the incident has started. Master instability from metadata scale or resource starvation causes the most severe outages. Low resource usage on a dedicated master is normal; spikes are the problem.

Raising limits instead of fixing root causes. Increasing thread pool queue sizes, raising circuit breaker limits, or adding heap delays failures without resolving them. Larger queues increase memory pressure. Higher breaker limits risk OOM.

Signals to watch in production

Signal	Why it matters	Warning sign
JVM heap used percent	Heap pressure triggers GC pauses and node removals	Sustained above 85%
Old GC frequency and duration	Stop-the-world pauses directly cause node departures	Old GC exceeding once per minute or pauses longer than 5 seconds
Thread pool rejections (write/search)	The node is at capacity and pushing back	Sustained nonzero rejections for more than 5 minutes
Circuit breaker trips	The node is protecting itself from OOM	Any increase in the `tripped` counter
Segment count per shard	More segments mean slower search and more heap metadata	More than 100 segments per active shard, or segment memory growing beyond 10% of heap
Pending cluster tasks	Master backlog indicates coordination instability	Pending tasks accumulating, or any task older than 1 minute
Disk usage vs watermarks	Watermarks trigger allocation changes and write blocks	Above the low watermark (85%)
Node count	Unexpected departures trigger reallocation storms	Unplanned decrease in data or master-eligible nodes
Fielddata cache size	Text field aggregations consume heap that doc_values avoid	Any significant fielddata usage on modern indices

How Netdata helps

Netdata collects these signals with per-second granularity.

Correlate JVM heap usage with GC pause duration and thread pool rejections on the same timeline to distinguish heap-bound slowdowns from I/O-bound slowdowns.
Track per-node disk usage against shard relocation activity to spot watermark cascades before flood stage blocks writes.
Monitor OS page cache hit ratio and disk I/O wait alongside search and indexing latency.
Alert on circuit breaker trips and thread pool queue depth deltas to catch backpressure before it becomes an outage.
Track node count drops and cluster state publication latency to detect master instability before fault detection removes nodes.

The Netdata solution

Elasticsearch monitoring with Netdata

Netdata monitors Elasticsearch with per-second metrics and ML anomaly detection. Correlate JVM heap pressure, shard counts, disk watermarks, mapping growth, and merge activity with cluster and node health in one view.

See Elasticsearch monitoring → Start monitoring free