Tuning Indexing Throughput
Indexing performance is dominated by how documents arrive and how the JVM heap and disk are used to process them. Sending documents via the _bulk API in reasonably sized batches (a common starting point is 5-15MB per bulk request, tuned empirically) amortizes network and per-request overhead far better than individual index calls; increasing refresh_interval (or temporarily setting it to -1 during a large bulk load) reduces how often Lucene has to open new searchable segments, which is expensive; and setting number_of_replicas to 0 during an initial bulk load (then restoring it afterward) avoids duplicating indexing work until the data is loaded, at the cost of temporarily reduced resilience. Multiple parallel bulk indexing clients, each targeting a reasonable number of shards, generally outperform a single-threaded client no matter how large its batches are, because Elasticsearch can pipeline work across shards concurrently.
Cricket analogy: A ground crew re-rolling and re-marking the pitch after every single delivery would grind play to a halt; doing it only at scheduled breaks (like raising refresh_interval) keeps the game moving efficiently.
# Temporarily relax refresh and replicas for a large initial bulk load
curl -X PUT "localhost:9200/products/_settings" -H 'Content-Type: application/json' -d'
{
"index": {
"refresh_interval": "-1",
"number_of_replicas": 0
}
}'
# ... run parallel _bulk indexing clients here ...
# Restore normal settings once the bulk load finishes
curl -X PUT "localhost:9200/products/_settings" -H 'Content-Type: application/json' -d'
{
"index": {
"refresh_interval": "1s",
"number_of_replicas": 1
}
}'Tuning Query Latency
Query performance benefits from mapping and query design choices made well before the query runs: using keyword fields (not text/analyzed fields) for filters, aggregations, and sorting avoids expensive on-the-fly work; structuring queries so filter clauses live in a bool query's filter context rather than must (filter context skips scoring and is cacheable) directly cuts CPU cost; and avoiding wildcard-leading queries (e.g., *searchterm) prevents Elasticsearch from having to scan the entire term dictionary instead of using an index. The request cache (for identical, deterministic search requests with size:0, common in dashboards) and the shard-level query cache for filter contexts both help repeated queries return near-instantly, but they only help when queries are structured to be cache-friendly and deterministic (avoiding now-relative date math without rounding, for instance).
Cricket analogy: A commentator citing a stat straight from a pre-built scorecard summary is far faster than recalculating from raw ball-by-ball data every time, mirroring how filter context avoids expensive scoring work.
JVM Heap and the Query Cache
Elasticsearch's JVM heap should generally be set to no more than 50% of available RAM (leaving the rest for the OS page cache, which Lucene relies on heavily for fast segment access) and never above roughly 30-32GB, because doing so disables the JVM's compressed ordinary object pointers (compressed oops) and effectively wastes memory rather than adding capacity. Beyond heap sizing, G1GC (the default garbage collector in modern Elasticsearch/JVM combinations) generally handles Elasticsearch's allocation patterns well, but frequent long GC pauses are a strong signal of heap pressure — often from oversized aggregations, excessive field data usage, or too many shards per node — and should be diagnosed via GC logs and the node stats API rather than solved by blindly increasing heap.
Cricket analogy: Overloading a team bus beyond its safe passenger limit doesn't get more players there faster, it just risks a breakdown — mirroring how heap beyond ~32GB stops helping and starts hurting due to lost pointer compression.
Never set the JVM heap above roughly 30-32GB even if the machine has far more RAM available: beyond that threshold, the JVM can no longer use compressed ordinary object pointers, effectively wasting memory and often performing worse than a smaller, compressed-oops-eligible heap. Give the remaining RAM to the OS page cache instead.
Force Merge and Segment Management
Lucene stores data in immutable segments, and every indexing operation eventually triggers background merges that combine smaller segments into larger ones to keep search efficient; too many small segments slow searches down because every query has to check every segment. For read-only indices (typically after an ILM rollover), running a force merge down to a small number of segments (often 1) meaningfully reduces memory overhead and speeds up searches, since Lucene per-segment data structures (like norms and doc values) have fixed overhead regardless of segment size. This should never be done on an index still receiving writes, since a force merge is I/O-intensive and creates new segments that immediately start fragmenting again as new documents arrive.
Cricket analogy: A groundsman consolidating scattered practice-net sessions into fewer, well-organized sessions once the tournament schedule is finalized (and no longer changing) makes logistics far more efficient, like force-merging a read-only index.
- Use the _bulk API with tuned batch sizes and parallel clients to maximize indexing throughput.
- Temporarily raising refresh_interval and setting replicas to 0 speeds up large initial bulk loads.
- Prefer filter context and keyword fields over scored, analyzed text for filters/aggregations/sorting.
- Avoid leading-wildcard queries, which force a full term-dictionary scan instead of an index lookup.
- Keep JVM heap at or below roughly 50% of RAM and never above ~30-32GB due to compressed oops.
- Diagnose GC pauses with node stats and GC logs rather than blindly increasing heap size.
- Force merge only read-only indices to reduce segment count and per-segment overhead.
Practice what you learned
1. Why is raising refresh_interval (or setting it to -1) helpful during a large bulk load?
2. Why should filter clauses be placed in a bool query's filter context instead of must?
3. What is the practical maximum recommended JVM heap size for an Elasticsearch node, and why?
4. Why is a leading-wildcard query like *searchterm expensive?
5. When is it appropriate to run a force merge on an index?
Was this page helpful?
You May Also Like
Shards and Replicas
How Elasticsearch splits indices into shards for scalability and duplicates them as replicas for resilience and read throughput.
Index Lifecycle Management
How Elasticsearch's ILM feature automates moving indices through hot, warm, cold, and delete phases as data ages.
Elasticsearch Cluster Architecture
How Elasticsearch nodes join together into a cluster, elect a master, and coordinate to store and serve data reliably.
Monitoring Elasticsearch
Which metrics, APIs, and alerting practices keep an Elasticsearch cluster healthy and catch problems before they cause outages.