<div dir="ltr">Thanks, Paul. I've played with SchedulerParameters=defer,... in and out of the configuration per various suggestions in various SLURM bug tracker threads that I looked at, but this was probably when we were still focusing on trying to get sched/backfill playing ball. I will try again now that we're back to sched/builtin and see if that helps. If we still see issues, I'll look at a potential DBD performance bottleneck and try some of those MySQL tuning suggestions I've seen in the docs.<div><br></div><div>Best,</div><div><br></div><div>Sean</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 8, 2017 at 3:57 PM, Paul Edmon <span dir="ltr"><<a href="mailto:pedmon@cfa.harvard.edu" target="_blank">pedmon@cfa.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So hangups like this can occur due to the slurmdbd being busy with requests.  I've seen that happen when an ill timed massive sacct request hits when slurmdbd is doing its roll up.  In that case the slurmctld hangs while slurmdbd is busy.  Typically in this case restarting mysql/slurmdbd seems to fix the issue.<br>
<br>
Otherwise this can happen due to massive traffic to the slurmctld.  You can try using the defer option for the SchedulerParamters.  That slows down the scheduler so it can handle the additional load.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Paul Edmon-</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 11/8/2017 3:11 PM, Sean Caron wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I see SLURM 17.02.9 slurmctld hang or become unresponsive every few days with the message in syslog:<br>
<br>
server_thread_count over limit (256), waiting<br>
<br>
I believe from the user perspective they see "Socket timed out on send/recv operation". Slurmctld never seems to recover once it's in this state and will not respond to /etc/init.d/slurm restart. Only after an admin does a kill -9 and restarts slurmctld does it snap back.<br>
<br>
I don't see anything else in the logs that looks like an error message that would help diagnose what is going on, even with log level debug3 on the SLURM controller daemon.<br>
<br>
I monitor CPU and memory utilization with "htop" on the machine running the controller daemon and it doesn't seem like it's overwhelmed by slurmctld load or anything like that.<br>
<br>
Machine running the controller daemon feels reasonable for the task, for the size of our cluster. It's a repurposed Dell PowerEdge R410 with 24 threads and 32 GB physical. Unless I'm way off?<br>
<br>
I tried all kinds of SchedulerParameter tweaks on sched/backfill and even set the scheduler back to sched/builtin and it's still happening. Didn't seem to affect the frequency much, either.<br>
<br>
Any thoughts what could be causing SLURM to spawn so many threads and hang up?<br>
<br>
Our cluster is medium-sized, we probably have a few thousand jobs in the queue on average at any given time.<br>
<br>
Monitoring with sdiag, the max cycle time of main scheduler never cracks 2 seconds. This seems reasonable?<br>
<br>
Thanks,<br>
<br>
Sean<br>
<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br></div>