[slurm-users] nodes going to down* and getting stuck in that state

Brian Andrus toomuchit at gmail.com
Thu May 20 16:25:51 UTC 2021


Does it tell you the reason for it being down?

sinfo -R

I have seen where a node comes up, but the amount of memory slurmd sees 
is a little less than what was configured in slurm.conf.
You should always set aside some of the memory when defining it in 
slurm.conf so you have memory for the operating system and so things 
don't choke if it comes up a bit lower because some driver took more 
memory when it loaded.

Brian Andrus

On 5/19/2021 9:15 PM, Herc Silverstein wrote:
> Hi,
>
> We have a cluster (in Google gcp) which has a few partitions set up to 
> auto-scale, but one partition is set up to not autoscale. The desired 
> state is for all of the nodes in this non-autoscaled partition 
> (SuspendExcParts=gpu-t4-4x-ondemand) to continue running 
> uninterrupted.  However, we are finding that nodes periodically end up 
> in the down* state and that we cannot get them back into a usable 
> state.  This is using slurm 19.05.7
>
> We have a script that runs periodically and checks the state of the 
> nodes and takes action based on the state.  If the node is in a down 
> state, then it gets terminated and if successfully terminated its 
> state is set to power_down.  There is a short 1 second pause and then 
> for those nodes that are in the POWERING_DOWN and not drained state 
> they are set to RESUME.
>
> Sometimes after we start up the node and it's running slurmd we cannot 
> get some of these nodes back into a usable slurm state even after 
> manually fiddling with its state.   It seems to go between idle* and 
> down*.  But the node is there and we can log into it.
>
> Does anyone have an idea of what might be going on?  And what we can 
> do to get these nodes back into a usable (I guess "idle") state?
>
> Thanks,
>
> Herc
>
>
>



More information about the slurm-users mailing list