Scheduler should not be considered idle while a client submits new work
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- python
- Área
- distributed-systems
Línea de trabajo
Comienza en Scheduler.update_graph y sigue el tratamiento del tiempo de espera por inactividad del scheduler durante el envío del grafo. Después, inspecciona cómo llegan los envíos del cliente al scheduler; se considera completado cuando el scheduler no se trata como inactivo mientras update_graph o un envío activo sigan en curso, y el comportamiento correspondiente está cubierto por pruebas.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Python
- Estrellas
- 1.7k
- Forks
- 778
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de dask/distributed
-
needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
dask/distributed#9366 ·
-
needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
dask/distributed#9353 ·
-
documentation
Dificultad 1/5 1-3 horas Aptitud para principiantes 82/100
dask/distributed#8304 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
dask/distributed#4816 · 2 comentarios ·
-
documentation good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
dask/distributed#2378 · 2 comentarios ·
Todos los issues de dask/distributed
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
spec-kitty/spec-kitty#5319 ·
Los mantenedores suelen responder en 1 día
-
backend::vllm diffusion multimodal
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
openai/openai-agents-python#5229 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día