<div dir="ltr">Hello,<div><br></div><div>This isn't precisely related, but I can say that we were having strange issues with system load spiking to the point that the nodes became unresponsive and likewise needed a hard reboot. After several tests and working with our vendor, on nodes that we entirely disabled swap, the problems ceased. You may have an absolutely valid need for swap, or some configurations may in fact rely on it for whatever reason, but for now we've chosen to disable swap on all nodes. It's interesting, however, because I didn't really identify the culprit, and it may be related to cgroups somehow, but regardless, disabling swap appears to be working for us with no immediate consequences.</div><div><br></div><div>Warmest regards,</div><div>Jason</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 16, 2023 at 10:59 AM Hermann Schwärzler <<a href="mailto:hermann.schwaerzler@uibk.ac.at">hermann.schwaerzler@uibk.ac.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Slurm users,<br>
<br>
after opening our new cluster (62 nodes - 250 GB RAM, 64 cores each - <br>
Rocky Linux 8.6 - Kernel 4.18.0-372.16.1.el8_6.0.1 - Slurm 22.05) for <br>
"friendly user" test operation about 6 weeks ago we were soon facing <br>
serious problems with nodes that suddenly become unresponsive (so much <br>
so that only a hard reboot via IPMI gets them back).<br>
<br>
We were able to narrow the problem down to one similar to this one:<br>
<a href="https://github.com/apptainer/singularity/issues/5850" rel="noreferrer" target="_blank">https://github.com/apptainer/singularity/issues/5850</a><br>
Although in our case it's not related to Singularity but generally to <br>
cgroups.<br>
<br>
We are using cgroups in our Slurm configuration to limit RAM, CPUs and <br>
devices. In the beginning we did *not* limit swap space (we are doing so <br>
now to work around the problem but would like to allow at least some <br>
swap space).<br>
<br>
We are able to reproduce the problem *outside* Slurm as well by using <br>
the small test program mentioned in the above Singularity GitHub-issue <br>
(<a href="https://gist.github.com/pja237/b0e9a49be64a20ad1af905305487d41a" rel="noreferrer" target="_blank">https://gist.github.com/pja237/b0e9a49be64a20ad1af905305487d41a</a>) with <br>
these steps (for cgroups/v1):<br>
<br>
cd /sys/fs/cgroup/memory<br>
mkdir test<br>
cd test<br>
echo $((5*1024*1024*1024)) > memory.limit_in_bytes<br>
echo $$ > cgroup.procs<br>
/path/to/mempoc 2 10<br>
<br>
After about 10 to 30 minutes the problem occurs.<br>
<br>
We tried to switch to cgroups/v2. Which does solve the problem for the <br>
manual case outside Slurm:<br>
<br>
cd /sys/fs/cgroup<br>
mkdir test<br>
cd test<br>
echo "+memory" > cgroup.subtree_control<br>
mkdir test2<br>
echo $((5*1024*1024*1024)) > test2/memory.high<br>
echo $$ > test2/cgroup.procs<br>
/path/to/mempoc 2 10<br>
<br>
Now it runs for days and weeks without any issues!<br>
<br>
But when we run the same thing in Slurm (with cgroups/v2 configured to <br>
*not limit* swapping) by using<br>
<br>
sbatch --mem=5G --cpus-per-task=10 \<br>
        --wrap "/path/to/mempoc 2 10"<br>
<br>
the nodes still become unusable after some time (1 to 5 hours) with the <br>
usual symptoms.<br>
<br>
Did anyone of you face similar issues?<br>
Are we missing something?<br>
Is it unreasonable to think our systems should stay stable even when <br>
there is cgroup-based swapping?<br>
<br>
Kind regards,<br>
Hermann<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;margin:0px"><span style="color:rgb(130,36,51)"><font face="Century Gothic"><b>Jason L. Simms, Ph.D., M.P.H.</b></font></span></div><font face="Century Gothic">Manager of Research Computing</font><br></div><div dir="ltr"><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;margin:0px"><font face="Century Gothic"><span style="color:gray">Swarthmore College<br>Information Technology Services</span></font></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;margin:0px"><font face="Century Gothic"><span style="color:gray">(610) 328-8102<br></span></font></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;margin:0px"><font face="Century Gothic">Schedule a meeting: </font><span style="font-family:Arial,Helvetica,sans-serif;font-size:small;color:rgb(32,33,36)"><a href="https://calendly.com/jlsimms" target="_blank">https://calendly.com/jlsimms</a></span><br></div></div></div></div></div></div>