Control idle time on SLURMCluster.adapt() to control when workers are released.
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
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- python
- Área
- distributed-systems, hpc
Línea de trabajo
El issue menciona SLURMCluster.adapt(), pero no indica archivos ni tests. Empieza localizando ese punto de entrada y leyendo cómo se liberan los workers adaptativos una vez completadas las tareas. Done debería proporcionar un mecanismo documentado para mantener los workers adquiridos a lo largo de una secuencia de cálculos retrasados sin un reencolado innecesario de SLURM.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The documentation gives the following example for using adapt and managing the lifetime of the workers:
`cluster = Cluster(
walltime="01:00:00",
cores=4,
memory="16gb",
worker_extra_args=["--lifetime", "55m", "--lifetime-stagger", "4m"],
)
cluster.adapt(minimum=0, maximum=200)
`
However, when using this on a SLURM HPC the behavior seems to be to release all the workers once the current task is done. Subsequent tasks will then requeue SLURM, which seems to lead to constant queuing and releasing of workers in my workflow.
I am hoping to accomplish something like the following:
`complex xarray computation 1
complex xarray computation 2
complex xarray computation 3
...
complex xarray computation N
`
but without releasing all the workers between serial executions. Is there currently a mechanism to complete a sequence of dask delayed tasks without releasing the workers gained from adapt()?
- Lenguaje dominante
- Python
- Estrellas
- 256
- Forks
- 148
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
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/dask-jobqueue
-
bug LSF
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
dask/dask-jobqueue#703 · 1 comentario ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
dask/dask-jobqueue#699 · 2 comentarios ·
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 38/100
dask/dask-jobqueue#692 · 1 comentario ·
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
dask/dask-jobqueue#691 · 7 comentarios ·
-
Dificultad 2/5 Medio día Aptitud para principiantes 45/100
dask/dask-jobqueue#686 · 3 comentarios ·
Todos los issues de dask/dask-jobqueue
Issues similares
-
tunneld on Windows: Wi-Fi devices are not discovered because uvicorn runs on a ProactorEventLoopAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
doronz88/pymobiledevice3#2051 ·
Los mantenedores suelen responder en 1 día
-
Remove DatacircleAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
collabnix/awesome-mcp-lists#230 ·
Los mantenedores suelen responder en 9 días
-
Groc schedules with out of range values pass config validation and fail later when the scheduler is builtPosiblemente ocupada @auraseb la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
autowarefoundation/autoware_carla_scenario#342 ·
Los mantenedores suelen responder en 1 día
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ianktoo/project-monitor#14 ·