Skip to content

Making delete, close and update-settings index IMMEDIATE in pending tasks #51781

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
garyelephant opened this issue Feb 1, 2020 · 2 comments
Closed
Labels
:Distributed Coordination/Task Management Issues for anything around the Tasks API - both persistent and node level.

Comments

@garyelephant
Copy link

garyelephant commented Feb 1, 2020

For now, close, delete and update-setting index is URGENT in pending tasks, as same as shard-failed and shard started, which means It always get stuck in closing and deleting indices when the cluster is in recovery.
However, close or delete or update-setting indices making elasticsearch recovery more faster, so is it possible to make Delete, Close Index IMMEDIATE in pending tasks ?

ES Version : 5.4.3
OS Version: CentOS 7

@garyelephant garyelephant changed the title Making Delete, Close Index IMMEDIATE in pending tasks Making delete, close and update-settings index IMMEDIATE in pending tasks Feb 1, 2020
@dliappis dliappis added the :Distributed Coordination/Task Management Issues for anything around the Tasks API - both persistent and node level. label Feb 3, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (:Distributed/Task Management)

@DaveCTurner
Copy link
Contributor

I think we should apply similar reasoning to my comment on another issue about promoting priorities across the board:

I do not think these should be IMMEDIATE tasks. There's something very wrong with the cluster if the master does not get around to lower priority tasks in a reasonably short amount of time, and the solution to that is definitely not to promote things to IMMEDIATE.

Note that we split up the historically-expensive shard-started task into a cheap URGENT part and a more expensive NORMAL part in #44433, and batched the more expensive parts together to avoid duplicate work. If we are still seeing URGENT-level tasks running unduly slowly then I would like more details so we can continue in this direction.

I am closing this as I think it is fixed in more recent versions; if you are still seeing issues with inappropriate priorities or slowly-running tasks in versions ≥7.4.0 then please get back in touch and we can reopen this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Task Management Issues for anything around the Tasks API - both persistent and node level.
Projects
None yet
Development

No branches or pull requests

4 participants