How to Supercharge Elasticsearch 7.8: Refresh, Replicas, Memory, and Query Tuning

Environment

Elasticsearch 7.8.0.

Optimizing Refresh Interval

Elasticsearch writes data to memory and flushes to disk based on index.refresh_interval (default 1 s). Increasing this interval reduces segment‑merge pressure. Set it when real‑time search is not required, either when creating an index or updating an existing one.

Reasonable Replica Count

Too many replicas slow indexing because each write must be replicated. During heavy initial indexing set number_of_replicas to 0 and increase it after the load finishes. The guide shows how to set replicas at creation and for existing indices.

Memory Configuration

Default heap is 1 GB, which is insufficient for production. Edit jvm.options to set identical -Xms and -Xmx values, e.g., 31 g. Keep heap below 50 % of physical RAM and preferably under 32 GB to avoid JVM and Lucene performance penalties.

Bulk Operations

For large write workloads use the Bulk API; the default max request size is 100 MB. Each line must end with a newline character and the request content type is application/x‑ndjson . Example payload:

<code>{
  "action": {}
}
{data}
# action values:
# create – document does not exist
# update – update document
# index – create or replace
# delete – delete document
</code>

Storage Device Optimization

Elasticsearch heavily accesses disks during segment merges; faster disks improve performance.

Mapping Design

Avoid nested or parent/child mappings when possible because they are slower. Limit nested_fields to 50 and keep total fields below default limits ( index.mapping.total_fields.limit: 1000 , index.mapping.depth.limit: 20 ). Excessive nested fields generate many internal documents, hurting query speed.

Additional limits: index.mapping.nested_objects.limit: 10000 , index.mapping.total_fields.limit: 1000 , index.mapping.depth.limit: 20 .

Query Optimization

Reduce the number of fields in query_string or multi_match queries; use copy_to to consolidate fields. Avoid using now in date queries to enable caching. Keep result set size reasonable; do not set size to Integer.MAX_VALUE . Prevent deep aggregation hierarchies that consume memory and CPU.

Done!