I'll note that the SLURM_CONF env var is listed on the sbatch docs page, so is
likely not an override for all slurm commands.
From: Groner, Rob via slurm-users
Sent: Tuesday, January 7, 2025 9:04 AM
To: slurm-users@lists.schedmd.com ; Sven Schulze
Su
The config file location is set during the ./configure step in building the
source code. I think it is --conf-dir or something. Do ./configure --help to
find the correct syntax. After configure, then rebuild and slurm will now look
in that new location.
There is also a SLURM_CONF env var tha
I'm not entirely sure, and I can't vouch for differences in a (relatively)
older version of slurm But I'm pretty sure on our cluster, we have to
specify the GRES in the partition in order for Slurm to treat them as
allocatable resources. On our interactive nodes, we have GPUs but we don't
So, the overall answer is yes. But there's a lot to it. I can't detail
everything we did to get where you're talking, but let me try to hit some high
points. Basically, google anything I'm about to mention to get a fuller
explanation:
*
You can set the "cost" of things per partition via th
Maybe I'm reading it wrong, but your partition sets DefMemPerGPU at 32000 and
the nodes only have 31000 real memory available.
Rob
From: Jörg Striewski via slurm-users
Sent: Wednesday, October 16, 2024 4:05 AM
To: slurm-users@lists.schedmd.com
Subject: [slurm-u
The trick, I think (and Guillaume can certainly correct me) is that the aim is
to allow the user to run as many (up to) 200G mem jobs as they wantso long
as they do not consume more than 200G on any single node. So, they could run
10 200G jobson 10 different nodes. So the mem limit isn
Ok, that example helped. Max of 200G on a single node, per user (not job). No
limits on how many jobs and nodes they can use...just a limit of 200G per node
per user.
And in that case, it's out of my realm of experience. 🙂 I'm relatively
confident there IS a way...but I don't know it offha
Ah, sorry, I didn't catch that from your first post (though you did say it).
So, you are trying to limit the user to no more than 200G of memory on a single
node? So if they submit a 2nd job, that job can start but will have to go onto
another node, and will again be restricted to 200G? So the
You have the right idea.
On that same page, you'll find MaxTRESPerUser, as a QOS parameter.
You can create a QOS with the restrictions you'd like, and then in the
partition definition, you give it that QOS. The QOS will then apply its
restrictions to any jobs that use that partition.
Rob
When you updated your operating system, you likely updated the version of slurm
you were using too (assuming slurm had been installed from system repos instead
of built source code). Slurm only supports db and state files that are within
2 major versions older than itself.
The fix is to uninst
Since you mentioned "an alternate configuration file", look at the bottom of
the sbatch online docs. It describes a SLURM_CONF env var you can set that
points to the config files.
Rob
____
From: Groner, Rob via slurm-users
Sent: Monday, May 20, 2024
It gets them from the slurm.conf file. So wherever you are executing
srun/sbatch/etc, it should have access to the slurm config files.
From: Alan Stange via slurm-users
Sent: Monday, May 20, 2024 2:55 PM
To: slurm-users@lists.schedmd.com
Subject: [slurm-users] R
FYI, I submitted a bug about this in March because the "compatible" line in the
docs was confusing to me as well. The change coming to the docs removes that
altogether and simply says that setting it to OFF "disables job preemption and
gang scheduling". Much clearer.
And we do it the same way
Marko,
We are running 23.02.6 and have a partition with a specific account set in
AllowAccounts. We test that only that account can use that partition, and it
works. I'll note that you'll need to set EnforcePartLimits=ALL in slurm.conf
for it to work, and if you use the job_submit filter, mak
14 matches
Mail list logo
