All,
When the slurm daemon is sending out emails, they are coming from “slurm(a)servername.subdomain.domain.edu<mailto:slurm@servername.subdomain.domain.edu>”. This has worked okay in the past, but due to a recent mail server change (over which I have no control whatsoever) this will no longer work. Now, the From: address is going to have to be something like “slurm-servername(a)domain.xn--edu-9o0a , or, at least something that ends in “(a)domain.xn--edu-9o0a (the subdomain being present …
[View More]will cause it to get rejected by the mail server.
I am not seeing in the documentation how to change the “From:” address tha slurm uses. Is there a way to do this and I’m just missing it?
---
Mike VanHorn
Senior Computer Systems Administrator
College of Engineering and Computer Science
Wright State University
265 Russ Engineering Center
937-775-5157
michael.vanhorn(a)wright.edu
[View Less]
So the squeue issue was resolved and was due to the partition being hidden.
Unhiding it solves the problem. However, the ssh issue remains (looks like
both were separate issues).
The pam_slurm_adopt is working on all the other nodes but not on the new
ones. Any idea how to solve this?
Best,
*Fritz Ratnasamy*
Data Scientist
Information Technology
On Thu, Jun 6, 2024 at 2:11 PM Ratnasamy, Fritz via slurm-users <
slurm-users(a)lists.schedmd.com> wrote:
> As admin on the cluster, …
[View More]we do not observe any issue on our newly added
> gpu nodes.
> However, for regular users, they are not seeing their jobs running on
> these gpu nodes when running squeue -u <username> ( it is
> however showing as running status with sacct) and they are not able to ssh
> to these newly added nodes when they have a running job on it.
> I am not sure if these 2 are related (not being to ssh to mgpu node with
> a running job on it and not listing a job with squeue for a user on the
> same node). There are no issues reported on the other nodes. Anyone know
> what is happening?
> Best,
>
> *Fritz Ratnasamy*
>
> Data Scientist
>
> Information Technology
>
>
> CAUTION: This email has originated outside of University email systems.
> Please do not click links or open attachments unless you recognize the
> sender and trust the contents as safe.
>
>
[View Less]
Thanks for the reply.
I was not aware of that change in 23.11. I am still using Slurm 23.02.7.
Best regards,
Pedro D.R. Santos
Specialist, Ph.D.,
High Performance Computing
Vestas Technology Centre Porto
Vestas Wind Systems A/S
Vestas will as part of your communication, interaction and business relationship with us collect and process personal data about you.
You can read more about Vestas' collection and processing of your personal data and your rights as a data subject in our Privacy …
[View More]Policy<https://www.vestas.com/en/about/profile/privacy-policy>.
Classification: Restricted
[View Less]
As admin on the cluster, we do not observe any issue on our newly added gpu
nodes.
However, for regular users, they are not seeing their jobs running on these
gpu nodes when running squeue -u <username> ( it is however showing as
running status with sacct) and they are not able to ssh to these newly
added nodes when they have a running job on it.
I am not sure if these 2 are related (not being to ssh to mgpu node with a
running job on it and not listing a job with squeue for a user on …
[View More]the same
node). There are no issues reported on the other nodes. Anyone know what is
happening?
Best,
*Fritz Ratnasamy*
Data Scientist
Information Technology
[View Less]
Hello everyone,
I am currently implementing a service to monitor for jwks key rotation. If a change is detected, the jwks file is updated. Is it enough to use "scontrol reconfigure" to reread the jwks file? Or does it require a full restart of the slurmctl daemon?
Thanks in advance for the inputs.
Best regards,
Pedro D.R. Santos
Specialist, Ph.D.,
High Performance Computing
Vestas Technology Centre Porto
Vestas Wind Systems A/S
+351 924 241 907
pddro(a)vestas.com<mailto:pddro@vestas.com…
[View More]>
http://www.vestas.com<http://www.vestas.com/>
Company reg. name: Vestas Wind Systems A/S
This e-mail is subject to our e-mail disclaimer statement.
Please refer to www.vestas.com/legal/notice<http://www.vestas.com/legal/notice>
If you have received this e-mail in error please contact the sender.
Vestas will as part of your communication, interaction and business relationship with us collect and process personal data about you.
You can read more about Vestas' collection and processing of your personal data and your rights as a data subject in our Privacy Policy<https://www.vestas.com/en/about/profile/privacy-policy>.
Classification: Restricted
[View Less]
At the moment we have 2 nodes that are having long wait times. Generally
this is when the nodes are fully allocated. What would be the other reasons
if there is still enough available memory and CPU available, that a
job would take so long? Slurm version is 23.02.4 via Bright Computing.
Note the compute nodes have hyperthreading enabled but that should be
irrelevant. Is there a way to determine what else could be holding jobs up?
srun --pty -t 0-01:00:00 --nodelist=node001 --gres=gpu:1 -A …
[View More]ourts -p short
/bin/bash
srun: job 672204 queued and waiting for resources
scontrol show node node001
NodeName=m001 Arch=x86_64 CoresPerSocket=48
CPUAlloc=24 CPUEfctv=192 CPUTot=192 CPULoad=20.37
AvailableFeatures=location=local
ActiveFeatures=location=local
Gres=gpu:A6000:8
NodeAddr=node001 NodeHostName=node001 Version=23.02.4
OS=Linux 5.14.0-70.13.1.el9_0.x86_64 #1 SMP PREEMPT Thu Apr 14 12:42:38
EDT 2022
RealMemory=1031883 AllocMem=1028096 FreeMem=222528 Sockets=2 Boards=1
State=MIXED ThreadsPerCore=2 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A
Partitions=ours,short
BootTime=2024-04-29T16:18:30 SlurmdStartTime=2024-05-18T16:48:11
LastBusyTime=2024-06-03T10:49:49 ResumeAfterTime=None
CfgTRES=cpu=192,mem=1031883M,billing=192,gres/gpu=8
AllocTRES=cpu=24,mem=1004G,gres/gpu=2,gres/gpu:a6000=2
CapWatts=n/a
CurrentWatts=0 AveWatts=0
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
grep 672204 /var/log/slurmctld
[2024-06-04T15:50:35.627] sched: _slurm_rpc_allocate_resources JobId=672204
NodeList=(null) usec=852
[View Less]
Hi,
my GPU testing system (named “gpu-node”) is a simple computer with one socket and a processor " Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz". Executing "lscpu", I can see there are 4 cores per socket, 2 threads per core and 8 CPUs:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): …
[View More]1
Vendor ID: GenuineIntel
CPU family: 6
Model: 26
Model name: Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
My “gres.conf” file is:
NodeName=gpu-node Name=gpu Type=GeForce-GTX-TITAN-X File=/dev/nvidia0 CPUs=0-1
NodeName=gpu-node Name=gpu Type=GeForce-GTX-TITAN-Black File=/dev/nvidia1 CPUs=2-3
Running “numactl -H” in “gpu-node” host, reports:
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 7809 MB
node 0 free: 6597 MB
node distances:
node 0
0: 10
CPUs are assigned 0-1 for first GPU and 2-3 for second GPU. However, “lscpu” shows 8 CPUs… If I rewrite “gres.conf” in this way:
NodeName=gpu-node Name=gpu Type=GeForce-GTX-TITAN-X File=/dev/nvidia0 CPUs=0-3
NodeName=gpu-node Name=gpu Type=GeForce-GTX-TITAN-Black File=/dev/nvidia1 CPUs=4-7
when I run “scontrol reconfigure”, slurmctld log reports this error message:
[2024-06-05T11:42:18.558] error: _node_config_validate: gres/gpu: invalid GRES core specification (4-7) on node gpu-node
So I think SLURM only can get physical cores and not threads, so my node only can serve 4 cores (in “lspcu”) but in gres.conf I need to write “CPUs”, not “Cores”… isn’t it?
But if “numactl -H” shows 8 CPUs, why I can use this 8 CPUs in “gres.conf”?
Sorry about this large email.
Thanks.
[View Less]
Hello,
I am trying to rewrite my gres.conf file.
Before changes, this file was just like this:
NodeName=node-gpu-1 AutoDetect=off Name=gpu Type=GeForceRTX2070 File=/dev/nvidia0 Cores=0-11
NodeName=node-gpu-1 AutoDetect=off Name=gpu Type=GeForceGTX1080Ti File=/dev/nvidia1 Cores=12-23
NodeName=node-gpu-2 AutoDetect=off Name=gpu Type=GeForceGTX1080Ti File=/dev/nvidia0 Cores=0-11
NodeName=node-gpu-2 AutoDetect=off Name=gpu Type=GeForceGTX1080 File=/dev/nvidia1 Cores=12-23
NodeName=node-gpu-3 …
[View More]AutoDetect=off Name=gpu Type=GeForceRTX3080 File=/dev/nvidia0 Cores=0-11
NodeName=node-gpu-4 AutoDetect=off Name=gpu Type=GeForceRTX3080 File=/dev/nvidia0 Cores=0-7
# you can seee that nodes node-gpu-1 and node-gpu-2 have two GPUs each one, whereas nodes node-gpu-3 and node-gpu-4 have only one GPU each one
And my slurmd.conf was this:
[...]
AccountingStorageTRES=gres/gpu
GresTypes=gpu
NodeName=node-gpu-1 CPUs=24 SocketsPerBoard=2 CoresPerSocket=6 ThreadsPerCore=2 RealMemory=96000 TmpDisk=47000 Gres=gpu:GeForceRTX2070:1,gpu:GeForceGTX1080Ti:1
NodeName=node-gpu-2 CPUs=24 SocketsPerBoard=2 CoresPerSocket=6 ThreadsPerCore=2 RealMemory=96000 TmpDisk=47000 Gres=gpu:GeForceGTX1080Ti:1,gpu:GeForceGTX1080:1
NodeName=node-gpu-3 CPUs=12 SocketsPerBoard=1 CoresPerSocket=6 ThreadsPerCore=2 RealMemory=23000 Gres=gpu:GeForceRTX3080:1
NodeName=node-gpu-4 CPUs=8 SocketsPerBoard=1 CoresPerSocket=4 ThreadsPerCore=2 RealMemory=7800 Gres=gpu:GeForceRTX3080:1
NodeName=node-worker-[0-22] CPUs=12 SocketsPerBoard=1 CoresPerSocket=6 ThreadsPerCore=2 RealMemory=47000
[...]
With this configuration, all seems works fine, except slurmctld.log reports:
[...]
error: _node_config_validate: gres/gpu: invalid GRES core specification (0-11) on node node-gpu-3
error: _node_config_validate: gres/gpu: invalid GRES core specification (12-23) on node node-gpu-1
error: _node_config_validate: gres/gpu: invalid GRES core specification (12-23) on node node-gpu-2
error: _node_config_validate: gres/gpu: invalid GRES core specification (0-7) on node node-gpu-4
[...]
However, even these errors, users can submit jobs and request GPUs resources.
Now, I have tried to reconfigure gres.conf and slurmd.conf in this way:
gres.conf:
Name=gpu Type=GeForceRTX2070 File=/dev/nvidia0
Name=gpu Type=GeForceGTX1080Ti File=/dev/nvidia1
Name=gpu Type=GeForceGTX1080Ti File=/dev/nvidia0
Name=gpu Type=GeForceGTX1080 File=/dev/nvidia1
Name=gpu Type=GeForceRTX3080 File=/dev/nvidia0
Name=gpu Type=GeForceRTX3080 File=/dev/nvidia0
# there is no NodeName attribute
slurmd.conf:
[...]
NodeName=node-gpu-1 SocketsPerBoard=2 CoresPerSocket=6 ThreadsPerCore=2 RealMemory=96000 TmpDisk=47000 Gres=gpu:GeForceRTX2070:1,gpu:GeForceGTX1080Ti:1
NodeName=node-gpu-2 SocketsPerBoard=2 CoresPerSocket=6 ThreadsPerCore=2 RealMemory=96000 TmpDisk=47000 Gres=gpu:GeForceGTX1080Ti:1,gpu:GeForceGTX1080:1
NodeName=node-gpu-3 SocketsPerBoard=1 CoresPerSocket=6 ThreadsPerCore=2 RealMemory=23000 Gres=gpu:GeForceRTX3080:1
NodeName=node-gpu-4 SocketsPerBoard=1 CoresPerSocket=4 ThreadsPerCore=2 RealMemory=7800 Gres=gpu:GeForceRTX3080:1
NodeName=node-worker-[0-22] SocketsPerBoard=1 CoresPerSocket=6 ThreadsPerCore=2 RealMemory=47000
# there is no CPUs attribute
[...]
With this new configuration, nodes with GPU start correctly slurmd.service daemon, but nodes without GPU (node-worker-[0-22]) can't start slurmd.service daemon and returns this error:
[...]
error: Waiting for gres.conf file /dev/nvidia0
fatal: can't stat gres.conf file /dev/nvidia0: No such file or directory
[...]
It seems SLURM is waiting that "node-workers" have also an nvidia GPU but not, theses nodes haven't GPU... So, where is my configuration error?
I have read in https://slurm.schedmd.com/gres.conf.html about syntax and examples but it seems I'm doing some wrong.
Thanks!!
[View Less]
Hi all,
I’m trying to pull (and understand) some GPU usage metrics for historical purposes, and dug into sacct’s TRES reporting a bit. We have AccountingStorageTRES=gres/gpu set in slurm.conf so we do see gres/gpuutil and gres/gpumem numbers available, but I’m struggling to find Slurm-side documentation that describes the units of these values. In looking at the code for gpu_nvml.c it seems the “nvmlDeviceGetProcessUtilization” function is being used and returns units in percentages, but I’m …
[View More]lost on the rest of the calculation.
Does anyone know if these units are percentages, and how they are calculated for the final job record, especially wrt multi-GPU jobs with a bunch of processes/moving parts? For context I’ve been looking at TRESUsageInTot and TRESUsageInAve so far. Also we’re currently running Slurm v23.02.6
Thanks in advance!
--
Jordan Robertson
Preferred pronouns: he/him/his
Technology Architect | Research Technology Services
DigITs, Technology Division
Memorial Sloan Kettering Cancer Center
929-687-1066
robertj8(a)mskcc.org<mailto:robertj8@mskcc.org>
=====================================================================
Please note that this e-mail and any files transmitted from
Memorial Sloan Kettering Cancer Center may be privileged, confidential,
and protected from disclosure under applicable law. If the reader of
this message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any reading, dissemination, distribution,
copying, or other use of this communication or any of its attachments
is strictly prohibited. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting this message, any attachments, and all copies and backups
from your computer.
Disclaimer ID:MSKCC
[View Less]
its friday and i'm either doing something silly or have a misconfig
somewhere, i can't figure out which
when i run
sbatch --nodes=1 --cpus-per-task=1 --array=1-100 --output
test_%A_%a.txt --wrap 'uname -n'
sbatch doesn't seem to be adhering to the --nodes param. when i look
at my output files it's spreading them across more nodes. in the
simple case above it's 50/50, but if i through a random sleep in,
it'll be more. and if i expand the array it'll use even more nodes.
i'm using con/tres …
[View More]and have cr_core_memory,cr_one_core_per_task set
[View Less]