Just fired up one more node, @Christian_Dahlqvist.
Do you believe that will also resolve the kinda slow response times that I am currently having?
ps: I am using t2.small.elasticsearch instance types
That depends on what you are doing. t2 instance types have very limited CPU allocated, so you can easily see poor performance if your workload uses a lot of CPU (well, it doesn't have to be a lot on those instances...). Using m4.large or m5.large instances will generally give you better and more predictable performance.
1 Like
Would not m4.large or m5.large be an overkill for 1000 documents?
Again, I am a beginner with ES thus sorry for these basic questions, @Christian_Dahlqvist
It probably would be overkill. If you only have that few documents I would reduce the number of primary shards for each index to 1.
It is however not always the data size that alone drives the amount of resources needed. If you threw a lot of inefficient wildcard queries against a data set of you size, you could probably end up saturating CPU on these nodes even though all data is effectively cached.
1 Like
I have no words for your support yesterday, @Christian_Dahlqvist (and @tdasch ).
This forum did not allow me to post more as a new user so here I come today back.
One more question, if you don't mind?
If you only have that few documents I would reduce the number of primary shards for each index to 1.
Would that bring me closer to reduce the response times from your point of view?
More than one shard per index for those volumes are unnecessary given you only have one node, and yes, it can improve performance.
1 Like
I now have 3 nodes, if that makes any difference?
Then I would still go with 1 primary shard, but 2 replicas so all nodes hold all data.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.