Very slow dashboards

Ah, apologies. I was going off of:

And

Yeah, 5120 would be the ideal # of shards.

Thank you @aaronsachs I’m going to get this implemented and monitor it over the next several days and will post back. Thank you very much.

Sure thing! I think all of us on this thread will be keen to hear about the end results. :smiley:

Wow is all I have to say. Though I’m sure it was already clear, but I was a victim of over sharding.

I was able to adjust my indices such that my shards were within the 10GB to 40GB range, reducing my shards to 3,359 (down from 19,328). Now everything is loading very speedy.

I clearly was paying too much attention to index size and not shard size.

Thank you all for taking the time to help me out with this issue.

3 Likes

I’m glad we were able to get to the bottom of the issue! Hopefully this takes a weight off going into the weekend and you’re able to enjoy it!

@jfurnier Glad we got to the bottom of this! Though Graylog software does a decent job at handling the underlying Elasticsearch node(s), it definitely still requires a degree of Elasticsearch expertise and capacity planning to manage effectively. Unfortunately, most people don’t realize there is an issue with Elasticsearch sizing for several weeks, once the cluster has already grown to near-dangerous levels.

Good luck with your project and feel free to DM me if you have any further questions or issues!

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.