aurora_cluster:how_scheduling_works
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
aurora_cluster:how_scheduling_works [2019/03/18 09:10] florido [Suggestion to self-regulate the usage inside a project] |
aurora_cluster:how_scheduling_works [2019/03/18 09:18] florido [Considerations on interactive sessions] |
||
|---|---|---|---|
| Line 19: | Line 19: | ||
| If the cluster is busy, requesting an interactive session may take time and fail. The scheduler will happily schedule resources for a user, but if the user asks for an interactive session with say 6 cores and there is no machine with 6 cores free, the scheduler cannot fulfil the request at the moment. | If the cluster is busy, requesting an interactive session may take time and fail. The scheduler will happily schedule resources for a user, but if the user asks for an interactive session with say 6 cores and there is no machine with 6 cores free, the scheduler cannot fulfil the request at the moment. | ||
| - | The scheduler treats an interactive job the same as a batch job, queueing it with the FIFO strategy described above. However, an exception to the FIFO scheduling appears when a parallel job is waiting for other jobs to finish and release resources. Then a short job can be promoted ahead of the queue, if it fits into an empty slot that is reserved for later use by the parallel job, so called backfill. Thus, queueing interactive jobs with shorter wall times have a higher probability of starting earlier. | + | The scheduler treats an interactive job the same as a batch job, queueing it with the FIFO strategy described above. However, an exception to the FIFO scheduling appears when a parallel job is waiting for other jobs to finish and release resources. Then a short job can be promoted ahead of the queue, if it fits into an empty slot that is reserved for later use by the parallel job, so called //backfill//. |
| + | |||
| + | Thus, queueing interactive jobs with shorter wall times have a higher probability of starting earlier. | ||
| Line 30: | Line 32: | ||
| * The project members should interact on a regular basis to understand what are their expected computing needs; | * The project members should interact on a regular basis to understand what are their expected computing needs; | ||
| - | * Those negotiated needs should be translated into *expected resource requests* | + | * Those negotiated needs should be translated into **expected resource requests** |
| * These requests should be documented somewhere FIXME on the cluster, like in a file. | * These requests should be documented somewhere FIXME on the cluster, like in a file. | ||
| * All users should honour the expected resource requests from the above file when submitting | * All users should honour the expected resource requests from the above file when submitting | ||
| * In order to preserve the possibility to use all of the nodes when needed, these requests should be flexible enough to be changed on the fly according to needs of the members of the project | * In order to preserve the possibility to use all of the nodes when needed, these requests should be flexible enough to be changed on the fly according to needs of the members of the project | ||
aurora_cluster/how_scheduling_works.txt · Last modified: 2019/08/27 10:28 by florido
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
