Elasticsearch optimization: shards, refresh_interval, queries

Elasticsearch optimization: where search breaks under load

An Elasticsearch cluster rarely breaks at once — it degrades gradually, and the first symptom is noticed not by an engineer but by a user: slow search under load, when results arrive in seconds instead of milliseconds.

The cause is most often data layout — index shards and segments are distributed unevenly, one node holds a hot shard with the bulk of traffic, the others sit idle, and adding replicas does not change the picture.

The second source is the index refresh mode.

Too frequent refresh_interval keeps fresh segments in memory and spends resources on rebuilding rather than search; merge cannot keep up with the write stream, the number of segments per shard grows, and every query reads more structures than needed.

On top of that come heavy queries — aggregations across the entire index, substring search, deep pagination: tolerable individually, together they consume memory and change the response profile.

The peak manifests as search degradation at peak: the query queue grows, search query latencies multiply, some requests fail by timeout, and the cluster spends time coordinating state between nodes instead of responding.

The cost is concrete: a user cannot find a product or document and leaves, while support receives a stream of complaints without a clear cause.

Elasticsearch optimization is not “tweaking parameters” but analyzing specific failure points: shard layout, refresh policy, and query profile. Let’s break down how this is addressed.

What Elasticsearch optimization delivers: speed and stability

Query response time in Elasticsearch is determined not by node power but by data layout and index refresh frequency.

As long as shards are distributed unevenly across nodes, and search queries fetch the entire result set, every catalog growth results in a longer response — first by fractions of a second, then by seconds, and users are the ones who notice.

A separate note on the load profile: search peak and write peak almost never coincide in nature.

If the index refresh interval is left at the default value, the cluster rebuilds segments on every batch of new data — under peak this creates a query queue and periodic timeouts that look like random failures.

Optimization eliminates this class of failures: the number of shards is brought in line with the volume a node can handle without skew, writes are switched to less frequent index refresh, and heavy queries are rewritten for what the screen actually displays instead of “fetch everything and sort on the application side.” Search speed increases on the same configuration, not by adding hardware.

The outcome is cluster stability and predictable operation under peak: response time stops depending on the daily rhythm, and the failure “search unavailable at peak hour” disappears from the statistics. Below we break down which parameters are responsible for this and how to check them on your index.

How the task is solved: sharding, reindexing, query tuning

Sharding in Elasticsearch is chosen once: the number of primary shards is fixed at index creation, and it cannot be changed without reindexing.

Therefore, first calculate the target volume and query profile, and only then touch the layout — otherwise there are more shards, and coordination between them costs more.

Some tasks are addressed without reindexing: the index refresh interval, query tuning, and replicas are changed on a live cluster. Below are the options actually chosen between, and their limitations.

What is taken in combination

In practice, options are combined: layout is changed once with headroom for growth, while the refresh interval and queries are tuned iteratively. Each change is tested on an index copy, and response time is compared before and after.

Work stages: from cluster audit to handover procedures

Elasticsearch optimization begins not with changing settings but with inventory. Changing the number of shards or the index refresh interval on a live cluster without measurement produces an effect that is hard to distinguish from coincidence. That is why we follow a fixed sequence — from audit to procedures for your team.

1. Cluster audit. Capture index sizes, shard distribution across nodes, memory consumption, queues, and response time. Record baseline metrics before any changes — otherwise the result cannot be proven.
2. Query profiling. Analyze the slow log and execution plans, find queries with full document scans and aggregations that recalculate the same data.
3. Index schemas. Rebuild field schemas and templates: number of shards and replicas, time-based partitioning, lifecycle rules for old data.
4. Operating mode tuning. Select the index refresh interval for the load profile: analytics does not need frequent refresh, search critically needs it.
5. Testing on production traffic. Run changes on part of the live stream and compare response time, failure rate, and resource consumption with baseline metrics.
6. Rollback plan. Prepare snapshots, previous templates and field schemas, and the condition under which we return to the original configuration.
7. Handover procedures. Provide documentation on indices, monitoring dashboards and alerts, and train the team to maintain the cluster independently.

Handover package: cluster diagrams, procedures, monitoring dashboards

Cluster handover does not end with search responding fast today. Without documented shard topology, access policies, and procedures, the team is left with a black box: the first mapping edit or index growth brings back degradations.

That is why we assemble the handover package as working documentation that allows operations to be run without us.

• Cluster diagram: nodes and their roles, shard and replica layout by index, shard size headroom, reindexing order as volume grows.
• Configuration documentation: refresh_interval values, analyzers, field limits — with an explanation of why this was chosen and what will change if edited.
• Maintenance procedure: version upgrades, segment merging, maintenance windows, actions on node failure and replica loss.
• Index access rights: application, analytics, and administrator roles, separate accounts, read-only mode for reporting marts.
• Monitoring dashboards: search and indexing latency, failure rate, task queue, shard state — with thresholds for on-call notification.
• Heavy query map: review of calls before and after optimization and a list of those cheaper to rewrite than to scale.
• Upgrade and rollback procedure: step-by-step sequence, checks after each step, and rollback points to the previous cluster state.

Case: catalog search stopped failing during peak hours

What was the bottleneck

A catalog with tens of thousands of items: under test load search held steady, but during evening peak hours response degraded.

The 99th percentile went beyond several seconds, some queries ended with a timeout error, and the cluster started rebalancing right under load — failure of one node pulled its neighbors along. Buyers complained that product selection “hung” exactly when the main revenue was happening.

What was changed and what it delivered

Data was spread so that search runs in parallel: the number of primary shards was aligned with the number of nodes, and heavy faceted queries were moved to a separate index.

refresh_interval was increased to 30 seconds where instant visibility is not needed — indexing stopped endlessly rebuilding segments. Deep pagination was replaced with cursor navigation: queries no longer read the entire index for the last pages of results.

Metrics before and after: the 99th percentile response time was cut by three times, the share of queries that failed by timeout — from a few percent to zero, and there were no cluster failures during peak for the entire observation period.

Indexing throughput approximately doubled without hardware replacement. The stack remained on Elasticsearch — we changed the storage schema and query profile, not the engine.

The head of department confirms: “Search is no longer a risk point during peak hours; it no longer needs to be watched manually.”

What to do if reindexing is impossible now

Reindexing on a live cluster is possible without stopping search — downtime is needed where the meaning of a field changes and old data cannot be read in the new way.

An index alias in Elasticsearch separates the name applications use from the physical index: the new version is built alongside, search serves current data, and the switch is a pointer change.

Working workarounds differ in cost and risk:

Gradual traffic migration is not “switch and forget.” First, a small share of requests goes to the alias, results on the new and old index are compared, and discrepancies are resolved before migrating all traffic. Rollback here is also a pointer change, so a failed release does not turn into manual data review.

Deferred edits accumulate debt unnoticed: analyzers diverge from actual query wording, shards outgrow a reasonable size, and the next reindexing requires noticeably more resources and fits worse with the planned window. “Do it later” is justified only where the edit does not affect result correctness.

Technical concerns: risks, rollback, version compatibility

Any intervention in a working search cluster starts with capturing the baseline state: an index snapshot, the current shard and replica map, the actual refresh interval, and the list of slow queries for the observation period.

Until this data is recorded, we do not change settings — it is used to build the rollback plan and verify that after the work the document count and control sample results match the reference.

Data integrity relies on operation order: first rebuild shards and replicas, wait for full copy recovery, and only then touch the index refresh interval and query wording.

Each step is applied separately, with a control measurement — it shows what had an effect and which step to roll back if things degrade.

The maintenance window is agreed in advance and stretched across stages: some settings are applied on the live cluster and are reversible with one command, while shard rebuilding is moved to hours of minimal load.

Configuration compatibility is checked before the work, not during — the cluster version, extension set, and index schemas are compared with the planned changes on a staging environment with a data copy.

Will compatibility with the current configuration and client code be preserved?

The response format and field schema remain the same, so application calls are not rewritten. If optimization requires changing a field type or name, we add an alias and a transition period during which both options work.

Let’s discuss your task: where do we start

For the assessment to be substantive rather than “plus-minus,” a short technical context is enough: it shows where the bottleneck is — in cluster topology, indexing settings, or the queries themselves.

Below is what to prepare for the discussion; if some data is missing, that is also a workable entry point, just the first step shifts to diagnostics.

• Topology: number of nodes and their roles, index sizes, number of shards and replicas, hot and cold storage distribution.
• Load profile: search-to-write ratio, daily volumes, peak windows, data freshness requirements.
• Metrics for a typical period: search and indexing latency, write queues, failures, storage growth rate.
• Current settings: refresh_interval, mappings, lifecycle policies, index templates, aggregation limits.
• List of heavy queries and aggregations users complain about — with example calls.
• What you already tried changing and what result it produced: this saves us a round of hypotheses.

Then we work as follows. The first step on your side is a conversation about the task and the materials from the list; on our side — configuration and query review, hypotheses on bottlenecks, and a work plan with stages.

In the plan we record which metrics are captured before and after each change and at what point we roll back if things get worse.

The next step is agreeing on scope: what we address immediately, and what in a separate iteration after verifying the effect. Describe the task in two or three paragraphs — we will return with an estimate and a plan.