5 Ways to Optimize Your OpenSearch Cluster

By: Jade Lassery

OpenSearch is a powerful, scalable search and analytics engine that can do amazing things for logging, observability, and full-text search. But like any distributed system, it only performs well if you keep it properly tuned and healthy. Ignore it, and you risk slower queries, higher costs, and even data loss.

Here are five practical tips to keep your OpenSearch cluster running smoothly and efficiently:

1. Balance Shards Across the Cluster

Shards are the backbone of OpenSearch’s data distribution. If shards aren’t spread evenly, some nodes get overloaded, leading to CPU bottlenecks and sluggish performance.

How to fix it:
Use the _cat/shards API or OpenSearch Dashboards to check shard placement. If it’s unbalanced, tweak shard allocation settings or enable automatic rebalancing with cluster.routing.rebalance.enable. Also, ensure every node is pulling its weight, sometimes nodes sit idle because of misconfigurations.

2. Choose the Right Number of Shards Per Index

It’s tempting to over-shard, especially with time-series data, but having too many shards – like five shards for a tiny daily index – creates hundreds of small shards eating up resources.

Keep shards sized between 10–50 GB. For smaller indexes, use the _shrink API after they go read-only, or start with fewer shards using templates that match your actual data size.

3. Control Field Explosion in Mappings

OpenSearch maps fields dynamically by default. While convenient, this can cause a mapping explosion when unpredictable log keys create tons of new fields, which wastes memory and risks hitting mapping limits.

Tip: Audit your index mappings regularly. Disable dynamic mapping where possible ("dynamic": false). When you need dynamic fields, flatten nested JSON or use runtime fields to keep things tidy. This helps improve both indexing and query speed.

4. Optimize Slow Queries

Slow queries can cripple your cluster, especially if they rely on expensive features like leading wildcards or huge aggregations.

Avoid costly patterns by using keyword fields for aggregations and filtered queries instead of full-text when you can. Turn on OpenSearch’s slow logs (index.search.slowlog.*) to spot troublemakers and optimize dashboards or apps. Also, limit heavy pagination or concurrent aggregations in high-traffic scenarios.

5. Investigate Slow Indexing

Slow indexing means longer delays for fresh data availability and higher resource consumption. For example: Large nested JSON documents with high cardinality fields can cause heap pressure and slow down the refresh process.

How to fix:

Tune refresh intervals: For heavy write loads, increase refresh interval (default 1s):

Use bulk indexing to reduce overhead instead of single-document writes.
Avoid high cardinality keyword fields or consider keyword normalization.
Monitor indexing with metrics like indexing.index_time and trace logs for bottlenecks.

Conclusion

Optimizing your OpenSearch cluster is an ongoing journey, not a one-time fix. Focus on balancing shards, managing mappings, tuning queries, and refining indexing behavior to keep performance high and costs low.

Start with these five areas and watch your cluster thrive.