The previous comment was incomplete, sorry: The first case is the main priority and the second one would be nice to have but not mandatory. Therefore we could live with the lack of tracking the completely unused allocations.
Best regards, Olli-Pekka On 22 May 2015, at 21:12, Olli-Pekka Lehto <[email protected]> wrote: > This would be fine, even with the caveat. Basically there are 2 use cases for > this that I’m looking at: > > 1. Running a standalone cycle-stealing application on the nodes that monitors > for opportunities to push small work packages onto idle cores > > 2. Being able to track "allocated vs. utilized” resource usage efficiency on > a node level in realtime with our node monitoring tools > (collectd+Graphite/Grafana) > > Best regards, > Olli-Pekka > > On 22 May 2015, at 20:59, Moe Jette <[email protected]> wrote: > >> >> What you are asking for does not exist today, but it would be relatively >> simple to add. There are already some RPCs that communicate only with a >> local slurmd on the compute node (see "scontrol listpids"). Note this would >> only work once the job has actually tried to launch something on the node >> (e.g. "salloc" by itself would not work unless Slurm was configured to >> launch a Prolog on every compute node at job allocation time). >> >> Quoting Olli-Pekka Lehto <[email protected]>: >>> Hi, >>> >>> I would like to regularly poll the resources reserved by SLURM on each >>> compute node with a very short interval. Is there some simple way to get >>> this information locally on each node, without having to poll the server. >>> The only thing that comes to mind immediately is to start digging into the >>> cgroups configuration on each node but I’m hoping there would be a simpler >>> solution. >>> >>> Best regards, >>> Olli-Pekka= >> >> >> -- >> Morris "Moe" Jette >> CTO, SchedMD LLC >> Commercial Slurm Development and Support >
