steps to speed up job submission?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 20/100
- Tipo de issue
- Documentación
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- r
- Área
- distributed-systems, hpc
Línea de trabajo
Comienza con la documentación de future.batchtools sobre el envío de trabajos, la asignación de SLURM, el inicio de los workers y la gestión de dependencias. Reproduce el retraso informado con un lote pequeño de trabajos y, a continuación, rastrea qué etapa representa ese tiempo. Se considera terminado cuando se explica la secuencia de envío y las opciones de configuración relevantes, o se identifica un problema de rendimiento específico.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I'm using future.batchtools via drake, and just got my first plan running on the cluster. It seems to take about one minute for each job submitted, and since I'm trying to submit several hundred jobs, that's not ideal (although it's not a deal-breaker, because I expect each job to take many hours to finish). I'm not sure what I might be able to change in order to speed this up. I haven't dived into the code, but my idea of what needs to happen to start a worker is:
- analyse the code to find dependencies
- submit the job to the scheduler (SLURM in my case)
- wait for the job to be allocated
- wait for the worker to start up (and load libraries?)
- send data to the worker (and libraries?)
Is this basically accurate?
Does the worker load libraries already installed on its node, or are all libraries sent to the worker by the master? If the latter, then reducing library dependencies seems like a potential avenue to try.
- Lenguaje dominante
- R
- Estrellas
- 87
- Forks
- 10
- Métricas de merge de PR
- Sin PR fusionados en 30 d
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 futureverse/future.batchtools
-
feature/resources scheduler/lsf
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
futureverse/future.batchtools#105 ·
-
feature/resources scheduler/sge
Dificultad 4/5 3-5 días Aptitud para principiantes 50/100
futureverse/future.batchtools#104 · 1 comentario ·
-
feature/resources scheduler/slurm
Dificultad 3/5 1-2 días Aptitud para principiantes 66/100
futureverse/future.batchtools#103 ·
-
Add batchtools_hyperqueue() Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 55/100
futureverse/future.batchtools#102 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 15/100
Todos los issues de futureverse/future.batchtools
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
briandconnelly/airnow#9 ·
-
Copy cohorts to keep old cohorts Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
OHDSI/CohortConstructor#774 ·
-
pre-review R TeX Track: 5 (DSAIS)
Dificultad 1/5 Menos de una hora Aptitud para principiantes 60/100
openjournals/joss-reviews#11330 · 7 comentarios ·
-
Release autosync 0.1.1 Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100