Update Slurm
7
Slurm.md
7
Slurm.md
@ -106,8 +106,11 @@ SLURM works with a "fair share" concept, which means that all users should get r
|
||||
Example: Users who have consumed fewer resources recently will have their jobs prioritized higher, while those who have used more will have lower priority, promoting balanced and fair resource distribution.
|
||||
|
||||
|
||||
**Some important info: **
|
||||
**Some important info/examples: **
|
||||
|
||||
- If you request 7 days for a job (maximum time) , the **JobSize** parameter will become
|
||||
- If you request 7 days for a job (maximum time), the **JobSize** parameter will become larger, meaning your jobs will have a **lower** priority --> try to request only the time that you will most likely need (plus a bit of backup time)
|
||||
- If you know that your job runs in <= one hour, go for the **hourly** / **gpu-short** partitions
|
||||
- Generally speaking: Try to minimize your request in terms of resources to maximize your priority!
|
||||
- If a job is queuing for an (unexpected) longer time, check the reason why the job is queuing (NODELIST(REASON)) from the `squeue` command. Adjust your job accordingly, if possible, or ask the admins to have a look if you are not sure about the issue.
|
||||
|
||||
|
||||
|
Reference in New Issue
Block a user