Elasticsearch index heavy reads

Elastic Stack Elasticsearch
1

i have 3 indices in the cluster that are read-heavy and the load on the nodes on which the shards of these indices are located is very high (the indexes are small, the largest index weighs 5 gigabytes)
we are thinking to provision a separate cluster for them

what do you do in such cases? or is it better to add more nodes to the existing cluster and label them as hot (sorry, not strong in elastic terminology) and schedule these indexes on them
but I see only 1 plus for this approach (do not provision additional cluster), but for the rest, the load will still go to the control plane (the same masters, all sorts of coordinator and ingest nodes)
It seems to me that it's still easier to provision separate cluster, or am I wrong?
Thanks in advance to everyone for the replies!

2

Welcome to our community! :smiley:

How big are your nodes in terms of hardware?

3

Thank you!
my nodes are
16 vCPU
16 GB ram ( 8 gb heap )
( i have 4 data only node and 1 master node )

4

That is not ideal, you have no redundancy if you lose that master node and your cluster will be unavailable.

Otherwise if your index is small and you have decent hardware support, we might need more info on why you think you have heavy read loads. Things like mappings, queries, query rates, logs etc.

5

@warkolm Sorry i have 2 another master eligble nodes, but 5 node is only master node

this index is used for GET user profile, and at the end of month ( when users get notification about bonuses ) almost all users login into application

and hot_threads shows that this index is under heavy load at this times

6

:grinning: any ideas? thank you

7

It's certainly much easier to manage one cluster, and I don't think it makes much difference in terms of performance because ...

... this reasoning is unsound. Master nodes and ingest nodes are not involved in searches, and you can scale searches horizontally a very long way within a single cluster.

8

@DavidTurner
Okay, so for example i have cluster of 5 nodes, and 1 index that has very intensive reads, so it can slow down all other indexes ( in terms of using Harware ) so i need to label this node as hot and migrate all shards to this nodes right?

9

I would expect scaling in to a single node would make things run a bunch slower. Surely you want to scale out?

10

How many primary and replica shards do these read intensive indices have?

How much data in total does each node hold?

11

for now i have 1 primary and 1 replica shards
in cluster i have about 150gb of all data, in read intensive indices i have 20gb @Christian_Dahlqvist

12

any ideas? thank you in advance!

13

The best way to support very high read or search rates against an index (or set of indices) is to ensure there is enough operating system page cache space to hold them in memory and avoid disk I/O when they are under heavy load. I would recommend having a single primary and a single replica shard for these read-heavy indices. This should allow them to largely fit into the page cache across your nodes. It may also be worthwhile looking into trimming you heap size if you have headroom there and thereby give more memory to the OS page cache.

14

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