Skip to content

Move data tier usage calculation to node level (#100230) #101128

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

gmarouli
Copy link
Contributor

Current situation
DataTiersUsageTransportAction executes an internal nodes stats action with all the trimmings:

 client.admin() 
     .cluster() 
     .prepareNodesStats() 
     .all() 
     .setIndices(CommonStatsFlags.ALL) 

This puts a lot of memory pressure to the coordinating node (which in this case is always the elected master) that can cause further instabilities.

Proposed solution

We could trim down the data we need since we only care about docs and store per shard, that would reduce what needs to be kept in memory; however, with the optimisations of the many shards project, we would like to make it even more light weight.

We chose to do this and to push some parts of the calculation to the nodes themselves. Namely, each node sends to the elected master, grouped per preferred tier:

  • A set of all indices residing in this node, so it can be used to count them.
  • A list of all the primary shard sizes residing in this nodes, so we can calculate statistics on them.
  • The count of total shards on the node.
  • The count of total docs on the node.
  • The total store size.

The elected master then collects the data and aggregates them to one response.

Fixes: #100230

@gmarouli gmarouli added >bug :Data Management/ILM+SLM Index and Snapshot lifecycle management labels Oct 19, 2023
@elasticsearchmachine elasticsearchmachine added Team:Data Management Meta label for data/management team v8.12.0 labels Oct 19, 2023
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-data-management (Team:Data Management)

@elasticsearchmachine
Copy link
Collaborator

Hi @gmarouli, I've created a changelog YAML for you.

@gmarouli gmarouli marked this pull request as draft October 19, 2023 13:24
@gmarouli
Copy link
Contributor Author

Reopened: #47875

@gmarouli
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/part-2

@gmarouli
Copy link
Contributor Author

@elasticmachine update branch

@gmarouli
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/part-2

@gmarouli gmarouli added the buildkite-opt-in Opts your PR into Buildkite instead of Jenkins label Oct 31, 2023
@gmarouli
Copy link
Contributor Author

@elasticmachine update branch

@elasticsearchmachine
Copy link
Collaborator

Hi @gmarouli, I've updated the changelog YAML for you.

@gmarouli
Copy link
Contributor Author

I am switching to build kite so I can re-run the failing test quicker.

I haven't been able to find the connection between the failing test and this code and I cannot reproduce it locally. But it appears that it fails consistently only in this PR so there must be something I am missing

@gmarouli
Copy link
Contributor Author

I cannot figure out why the test is failing. I opened another PR in which I am going to apply the changes step by step and see which one is triggering the test failure.

@gmarouli
Copy link
Contributor Author

Also I was just able to reproduce it the failure when it runs in the whole suite not as an individual test, I will follow up on this too.

@gmarouli
Copy link
Contributor Author

gmarouli commented Nov 1, 2023

Duplicate of #101599

@gmarouli gmarouli marked this as a duplicate of #101599 Nov 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug buildkite-opt-in Opts your PR into Buildkite instead of Jenkins :Data Management/ILM+SLM Index and Snapshot lifecycle management Team:Data Management Meta label for data/management team v8.12.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DataTiersUsageTransportAction is incredibly inefficient in large clusters
3 participants