User Jobs

GiulioFontana — Wed, 04 Nov 2026 14:33:26 GMT

Options of srun and sbatch

← Older revision		Revision as of 14:33, 4 November 2026
Line 64:		Line 64:

	:;‑‑gres=<gpu_resources>		:;‑‑gres=<gpu_resources>
	:: specifies what GPUs to assign to the job. <code>gpu_resources</code> is a comma-delimited list where each element has the form <code>gpu:<Type>:<amount></code>, where <code><Type></code> is one of the types of GPU available on Mufasa (see [[SLURM#gres syntax\|<code>gres</code> syntax]]) and <code><amount></code> is an integer between 1 and the number of GPUs of such type available to the partition. For instance, <code><gpu_resources></code> may be <code>~~gpu:40gb:1,~~gpu:3g.20gb:1</code>, corresponding to asking for one ~~"full" GPU and 1~~ "small" GPU.		:: specifies what GPUs to assign to the job. <code>gpu_resources</code> is a comma-delimited list where each element has the form <code>gpu:<Type>:<amount></code>, where <code><Type></code> is one of the types of GPU available on Mufasa (see [[SLURM#gres syntax\|<code>gres</code> syntax]]) and <code><amount></code> is an integer between 1 and the number of GPUs of such type available to the partition. For instance, <code><gpu_resources></code> may be <code>gpu:3g.20gb:1</code>, corresponding to asking for one "small" GPU.

	:: ''Important! The <code>‑‑gres</code> parameter is '''mandatory''' if the job is run with a QOS that allows access to the system's GPUs. Differently from other resources (where unspecified requests lead to the assignment of a default amount), GPUs must always be explicitly requested.''		:: ''Important! The <code>‑‑gres</code> parameter is '''mandatory''' if the job is run with a QOS that allows access to the system's GPUs. Differently from other resources (where unspecified requests lead to the assignment of a default amount), GPUs must always be explicitly requested.''

	:;‑‑mem=<mem_resources>		:;‑‑mem=<mem_resources>
	:: specifies the amount of RAM to assign to the job; for instance, <code><mem_resources></code> may be <code>~~200G~~</code>		:: specifies the amount of RAM to assign to the job; for instance, <code><mem_resources></code> may be <code>32G</code>

	:;‑‑cpus-per-task=<cpu_amount>		:;‑‑cpus-per-task=<cpu_amount>

SLURM

GiulioFontana — Wed, 04 Nov 2026 09:13:06 GMT

Elements determining job priority

← Older revision		Revision as of 09:13, 4 November 2026
(35 intermediate revisions by the same user not shown)
Line 277:		Line 277:
	::: Used to provide higher priority to jobs asking for '''less resources'''		::: Used to provide higher priority to jobs asking for '''less resources'''

	: '''Number of CPUs''' requested by the job ~~(also called "job size")~~		: '''Number of CPUs''' requested by the job
	::: Used to provide higher priority to jobs asking for '''a lower number of CPUs'''		::: Used to provide higher priority to jobs asking for '''a lower number of CPUs'''

	~~: '''Job duration''', i.e. the execution time requested by the job~~
	~~::: Used to provide higher priority to '''shorter jobs'''~~

	: '''Job Age''', i.e. the time that the job has been waiting in the queue		: '''Job Age''', i.e. the time that the job has been waiting in the queue
Line 288:		Line 285:
	: '''FairShare''', i.e. a factor computed by SLURM to balance use of the system by different users		: '''FairShare''', i.e. a factor computed by SLURM to balance use of the system by different users
	::: Used to provide higher priority to jobs by users who '''used Mufasa's resources less than others''' (see [[#How FairShare works\|below]])		::: Used to provide higher priority to jobs by users who '''used Mufasa's resources less than others''' (see [[#How FairShare works\|below]])

			You can understand how each of these elements contributes to the priority of the jobs waiting for execution (both yours and of other users) with command <code>sprio</code>. A tailored version of <code>sprio</code> that only displays the parameters listed above is the following:
			<pre style="color: lightgrey; background: black;">
			sprio -o "%6i %9u %.8Y %.10B %.5Q %.9T %.5A %.5F"
			</pre>

			Here is an example of the output of the command above:
			<pre style="color: lightgrey; background: black;">
			JOBID USER PRIORITY ASSOC QOS TRES AGE FAIRS
			5790 amoglia 3495 2500 375 cpu=-800 933 487
			5791 qliu 3010 2500 375 cpu=-800 916 19
			5817 mzoccola 2336 625 750 cpu=-800 495 1266
			5822 fbottazzi 2235 625 750 cpu=-600 467 994
			5837 lpassoni 2508 2500 750 cpu=-800 0 58
			5838 bagostini 4437 625 3000 cpu=-200 0 1013
			5839 flazzaro 1549 625 750 cpu=-800 0 974
			</pre>
			In it, column PRIORITY provides the overall priority of each job. Each priority value is the sum of the five values to its right; in particular, column ASSOC corresponds to user category, while column TRES corresponds to the number of CPUs. Note that the contribution of TRES to priority is ''negative'', i.e. it is a penalty; its value is proportional to the number of CPUs requested by the job.

			'''Things to consider when using <code>sprio</code>'''
			* Its output is only relevant for jobs ''not yet in execution''. For an already running job, the values shown by <code>sprio</code> correspond to the priority that the job would get if evaluated now, which generally differs from its actual priority.
			* Jobs listed by <code>sprio</code> may temporarily differ from jobs listed by <code>squeue</code>: this is due to the fact that SLURM updates its internal data with a periodicity of a few minutes.

	=== How FairShare works ===		=== How FairShare works ===
Line 313:		Line 332:
	:: Usually, code exploits multiple CPUs only if specifically designed to do so: if unsure, only ask for 1 CPU		:: Usually, code exploits multiple CPUs only if specifically designed to do so: if unsure, only ask for 1 CPU
	:: The fewer resources your job asks for, the less it will wait before they become available		:: The fewer resources your job asks for, the less it will wait before they become available
			:: The more CPUs your job asks for, the stronger the penalty to its priority
	:: Asking for fewer CPUs and/or less RAM improves your FairShare		:: Asking for fewer CPUs and/or less RAM improves your FairShare

Line 405:		Line 425:
	AllowGroups=ALL AllowAccounts=ALL AllowQos=nogpu,gpulight,gpu,gpuwide,gpuheavy-20,gpuheavy-40		AllowGroups=ALL AllowAccounts=ALL AllowQos=nogpu,gpulight,gpu,gpuwide,gpuheavy-20,gpuheavy-40
	AllocNodes=ALL Default=YES QoS=N/A		AllocNodes=ALL Default=YES QoS=N/A
	=> DefaultTime=01:00:00 DisableRootJobs=NO ExclusiveUser=NO ExclusiveTopo=NO GraceTime=0 Hidden=NO		DefaultTime=01:00:00 DisableRootJobs=NO ExclusiveUser=NO ExclusiveTopo=NO GraceTime=0 Hidden=NO
	MaxNodes=UNLIMITED MaxTime=3-00:00:00 MinNodes=0 LLN=NO MaxCPUsPerNode=UNLIMITED MaxCPUsPerSocket=UNLIMITED		MaxNodes=UNLIMITED MaxTime=3-00:00:00 MinNodes=0 LLN=NO MaxCPUsPerNode=UNLIMITED MaxCPUsPerSocket=UNLIMITED
	Nodes=gn01		Nodes=gn01
Line 412:		Line 432:
	State=UP TotalCPUs=48 TotalNodes=1 SelectTypeParameters=NONE		State=UP TotalCPUs=48 TotalNodes=1 SelectTypeParameters=NONE
	JobDefaults=(null)		JobDefaults=(null)
	=> DefMemPerNode=4096 MaxMemPerNode=UNLIMITED		DefMemPerNode=4096 MaxMemPerNode=UNLIMITED
	TRES=cpu=48,mem=1011435M,node=1,billing=49,gres/gpu=13,gres/gpu:3g.20gb=5,gres/gpu:40gb=3,gres/gpu:4g.20gb=5		TRES=cpu=48,mem=1011435M,node=1,billing=49,gres/gpu=13,gres/gpu:3g.20gb=5,gres/gpu:40gb=3,gres/gpu:4g.20gb=5
	TRESBillingWeights=cpu=1.0,gres/gpu:3g.20gb=6.0,gres/gpu:4g.20gb=6.0,gres/gpu:40gb=6.0,mem=0.05g		TRESBillingWeights=cpu=1.0,gres/gpu:3g.20gb=6.0,gres/gpu:4g.20gb=6.0,gres/gpu:40gb=6.0,mem=0.05g
	</pre>		</pre>

	In the ~~example, we have highlighted with '''=~~>~~'''~~ the most relevant default values for Mufasa users~~, i.e.~~:		In the output of <code>scontrol show partition</code> the most relevant default values for Mufasa users are:

	;<code>DefaultTime</code>		;<code>DefaultTime</code>

Mufasa (BioHPC) - Recent changes [en]

User Jobs

SLURM