{"id":5923,"date":"2020-07-15T12:09:21","date_gmt":"2020-07-15T11:09:21","guid":{"rendered":"https:\/\/research.reading.ac.uk\/act\/?post_type=kbe_knowledgebase&p=5923"},"modified":"2026-01-09T18:24:41","modified_gmt":"2026-01-09T18:24:41","slug":"racc-slurm-commands-and-resource-allocation-policy","status":"publish","type":"kbe_knowledgebase","link":"https:\/\/research.reading.ac.uk\/act\/knowledgebase\/racc-slurm-commands-and-resource-allocation-policy\/","title":{"rendered":"Reading Academic Computing Cluster – Slurm commands and resource allocation policy"},"content":{"rendered":"

(work in progress)<\/p>\n

Resources and limits<\/h2>\n

Partitions:<\/strong><\/p>\n

In SLURM, partitions are (possibly overlapping) groups of nodes. Partitions are similar to queues in some other batch systems, e.g. in SGE on met-cluster and maths-cluster. The default partition is called \u2018cluster\u2019 and it is has 24 hours default time limit, and the maximum time limit is 30 days, but we do not recommend running jobs that long. There is also the ‘limited’ partition, with maximum time limit of 24 hours. The partition ‘limited’ allows access to some of the ‘project’ nodes.<\/p>\n\n\n\n\n\n\n\n\n\n
partition<\/td>\nlimits<\/td>\ndescription<\/td>\n<\/tr>\n
cluster<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
limited<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
gpu<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
gpu_limited<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
project<\/td>\n<\/td>\n<\/td>\n<\/tr>\n
custom project partitions<\/td>\n<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The cluster currently consists of over 50 compute nodes, with core counts varying between 8-cores up to 24-cores per node. There is also a node with 4 GPU devices.<\/p>\n

Time and memory limits:<\/strong><\/p>\n

The default time limit in the \u2018cluster\u2019 partition is 24 hours and the default memory limit is 1 GB per CPU core. The maximum time limit is 30 days, and the maximum memory limit is not set, it is limited only by the hardware capacity. Users are expected to properly estimate their CPU and memory requirements. Over-allocating resources will prevent other users from accessing unused memory and CPU time.<\/strong> Also, previously consumed resources are used to compute user\u2019s fair-share priority factor, and overprovisioning jobs will have a negative effect on future user\u2019s job priority.<\/p>\n

The CPU and memory limits will be strictly enforced by the scheduler. Tasks will be limited to run on the requested number of CPU cores, e.g. if you request one CPU core and run a parallel job, all your threads or processes will run on a single CPU core. Processes, which exceed their memory allocation will be killed by the scheduler.<\/p>\n

Fair share policies:<\/strong><\/p>\n

Jobs waiting to be scheduled are ordered according to a multifactor priority. The fair-share component is based on<\/p>\n