Scheduler should not be considered idle while a client submits new work
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- distributed-systems
Direzione di ricerca
Inizia da Scheduler.update_graph e traccia la gestione dell’idle-timeout dello scheduler durante l’invio del grafo. Poi esamina come gli invii del client raggiungono lo scheduler; il lavoro è completato quando lo scheduler non viene trattato come inattivo mentre update_graph o un invio attivo è ancora in corso, e il comportamento pertinente è coperto dai test.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Describe the issue:
I have seen several instances where a cluster with an idle timeout shut down because it took an excessive amount of time for the client to submit new work. In these cases, the scheduler should not have shut down because but rather anticipated that new work will arrive shortly.
As far as I can tell, we can address this in two steps:
- We should not consider the scheduler idle while
Scheduler.update_graphexecutes. This method is the main entry point for submitting new work to the cluster and it can take a while when encountering large or complex task graphs, resulting in a cluster shutting down while the scheduler is already preparing future work. - We should not consider the scheduler idle while a client submits new work. This is more complex. One possible solution would be for the client to announce to the scheduler that it starts submitting work. The scheduler will then have to ensure that it doesn't block being idle longer than necessary, i.e., handling submission attempts and client timeouts.
- Lingua principale
- Python
- Stelle
- 1.7k
- Fork
- 778
- Merge medio
- 1h 36m
- PR unite (30g)
- 1
Preparare l'ambiente
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di dask/distributed
-
needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
dask/distributed#9366 ·
I maintainer di solito rispondono entro 1 giorno
-
needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
dask/distributed#9353 ·
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 1/5 1-3 ore Idoneità per principianti 82/100
dask/distributed#8304 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
dask/distributed#4816 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
documentation good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
dask/distributed#2378 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di dask/distributed
Issue simili
-
bug status/needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
prowler-cloud/prowler#12887 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
area: desktop platform: macos priority: p3 status: ready type: enhancement
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
use-agent-os/agent-os#3484 ·
I maintainer di solito rispondono entro 2 giorni
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
open-telemetry/opentelemetry-python-contrib#5113 · 2 commenti · 2 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
external
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
langchain-ai/docs#6255 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno