Phoenix cluster policy

From CsWiki
Revision as of 16:57, 11 February 2021 by Irush (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The phoenix cluster policy works mainly by pool of resources limits. Each contribution is counted according to the CPUs, Memory, and GPUs added to the cluster. The different types of CPUs or GPUs aren't taken into account.

This policy is effective since Feb. 14 2021.


Each CS lab (PI) has a slurm account on the phoenix cluster. Each such account is limited by the lab's contribution to the cluster.

For example, if a lab contributed 2 nodes with 8 CPUs, 500G RAM, and 2 GPUs each. Than that lab won't be able to use more than 16 CPUs, 1T RAM and 4 GPU at any given time.

Due to scheduling constrains, especially when the cluster is loaded, jobs might still get delayed before the lab limit has been reached.

To check the account usage and limits, one can use the slimits utility:


killable (preemptable)

All accounts have access to the killable account. This account doesn't have limits, but jobs there can be killed by "normal" jobs.

Courses, projects (e.g. engineering), and labs which didn't contribute to the cluster can only run on the killable account.

Jobs in the killable account have the lowest priority.


The priority is a number assigned to each job which determine the order in which the scheduler will try to schedule the jobs.

The priorities are not related to the limits. High priority jobs might not run because the lab has reached its resources limits. In which case lower priority jobs will start before the higher priority ones.

Currently there are no priorities differences between accounts. All accounts are equal priority-wise. A lab which bought more resources - will have higher limits, not higher priority.

The main priority factor is the fair-share. The more a user (or a lab) has used in the past, the lower the priority he'll have. Currently only CPU time is taken into account for usage history, but this might change in the future and different weights can be given to different resources (CPU, memory, GPU). The historic usage for the fair-share calculation has a half life decay of 7 days.

Future Changes

Another layer of killable jobs. Labs could pay for <resource>-time (cpu-time, gpu-time, etc.). These jobs will have priority between "killable" jobs and "normal" jobs. They could kill killable jobs and could be killed by "normal" jobs.

Cross cluster jobs

Slurm supports cluster federation, in which jobs are sent to all clusters which the user/account can run on. This could help users who have access to other clusters such as hm or blaise. Or generally increase utilization if the killable jobs could also migrate.