Loading

Shard Too Large

One or more shards exceed recommended size limits (roughly 50 GB or very high document counts). Oversized shards slow recovery, relocation, and search, and in extreme cases can become hard to move or write.

Note

For a complete list of insights, refer to AutoOps insights.

Field Value
Component Elasticsearch
Severity Medium
Scope Index
Domains performance, index-management, shard-allocation

You can customize these settings to adjust when AutoOps detects this event and presents the insight. Refer to AutoOps event settings for details.

The default customization settings are:

Setting Type Default
Maximum optimal shard size in GB Integer 0.0004
Exclude indices based on this pattern List of strings

The following is an example of what you might see when this insight is triggered. Real insights use live data and links from your deployment or cluster.

Total number of indices with large shards: 12 The index that contains the largest shard is: logs-prod-000045, and the shard size is: 42,000,000. See a sample list: logs-prod-000045, logs-prod-000046.

Note

AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.

Impact: Large shards can cause slow searches and decrease cluster performance. A shard that greatly exceeds the recommended limit of 50GB or that contains more than 2B documents might become corrupted or unwritable. Index data is partitioned into shards, and the number of shards in an index depends on the index settings used when the index was originally created. It is recommended not to surpass 50GB for a single shard and to try not to store more than 200M documents per shard. Beyond this size your shard might become unwritable, or cluster might be cannot relocate or recover index shards.