I'm currently working with a single node Elastic Stack deployment. System specifications are 2 CPU / 8 GB RAM / 500 GB SSD. I've implemented most if not all optimization best practices (minus index / shard sizing).
I'm starting to notice that queries are taking longer and long as the number of indices and shards grow. We've got 59 indices / 455 total shards / 220 unassigned shards / 28 million documents / 21 GB data.
I've done some reading in the docs and came to the following conclusions:
- Since I'm using a single Elasticsearch node, having an index config with 5 shards / 1 replica per shard (shown below), is consuming unnecessary resources.
GET /winlogbeat-6.4.0-redacted/_settings
{
"winlogbeat-6.4.0-redacted": {
"settings": {
"index": {
"mapping": {
"total_fields": {
"limit": "10000"
}
},
"refresh_interval": "5s",
"number_of_shards": "5",
"provided_name": "winlogbeat-6.4.0-redacted",
"creation_date": "redacted",
"number_of_replicas": "1",
"uuid": "redacted",
"version": {
"created": "redacted"
}
}
}
}
}
Question: Should I consider shrinking my indices to 3 shards per index with 0 replicas? Or would it be even better to shrink my indices to 1 shard / 0 replicas? I don't anticipate indices to go above 10 GB in size during production.
This would be useful for a single node setup only, I think. When we scale to 3 Elasticsearch nodes I will switch to 3 or 5 shards with 1 replica per shard.
Thanks for reading!