Skip to content
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

[Enhancement] Cluster health API uses 36% of memory allocations during index creation #11684

Open
amkhar opened this issue Dec 28, 2023 · 1 comment
Assignees
Labels
bug Something isn't working Cluster Manager

Comments

@amkhar
Copy link
Contributor

amkhar commented Dec 28, 2023

Describe the bug

While using a large cluster with more than 300K shards, if we start creating index, it takes more than 15 seconds. To optimize this flow, we should use less resource in terms of CPU and JVM.

_cluster/health API flow takes more than 36% of memory allocations (see attached image of async-profiler for reference). 20% of it is taken in calculating the health and 16% is taken in just constructing the response.

Related component

Cluster Manager

To Reproduce

  1. Create a 300 node cluster with 300K shards.
  2. Start new index creation.
  3. Take async profiler alloc profile on active cluster manager node.
  4. See that cluster/health flow takes more than 36% of memory allocations

Expected behavior

Ideally it should be optimized to use lesser resources. If possible we can pre-compute health for a particular cluster state version, so whenever it's needed, we don't do whole re-computation again if version is same.

Additional Details

Screenshots
github-upload-cluster-health-takes-36%-allocations-during-index-creation-1

@SwethaGuptha
Copy link
Contributor

Addressed in #15492

@rwali-aws rwali-aws moved this from 🆕 New to 👀 In review in Cluster Manager Project Board Sep 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Cluster Manager
Projects
Status: 👀 In review
Development

No branches or pull requests

3 participants