On 27/11/14 07:49, Christopher B Coffey wrote:
> Anyone see any issues with this? Are you using CR_Core_Memory at your
> site?
We are using CR_Core_Memory here with cgroup enforcement and tracking
here with no issues.
Prior to upgrading to 14.03 from 2.6.x we didn't use cgroups for
accounting
Hey Chris,
We're using CR_Core_Memory with the following configuration
SelectTypeParameters=CR_Core_Memory
DefMemPerCPU=2000
MaxMemPerCPU=2000
NodeName=node[1-11] RealMemory=32000 TmpDisk=35 Sockets=2 CoresPerSocket=8
ThreadsPerCore=1 State=Idle
The result is that requesting more Ram caus
Hello,
Up till now I’ve been using cores as a consumable resource on our cluster
with:
SelectType=select/cons_res
SelectTypeParameters=CR_Core
This has worked out mostly great. However, I’ve had a few occurrences
recently where some jobs have been using more memory then they should and
effect
On Wed, Nov 26, 2014 at 10:38:36AM -0800, je...@schedmd.com wrote:
>
> We have just released Slurm version 14.11.1. This includes a fix for
thanks, make check && make install on my CentOS-6 boxes.
Best regards
Tru
--
Dr Tru Huynh | http://www.pasteur.fr/research/bis
mailto
We have just released Slurm version 14.11.1. This includes a fix for a
race condition that can deadlock the slurmctld daemon when job_submit
plugins are used, plus a few minor changes as identified below. You
can download it from:
http://www.schedmd.com/#repos
* Changes in Slurm 14.11.1
=
Roshan,
It depends on several things including if the start time is set based on
when slurmctld says "launch" and the job actually launches (don't know),
whether the end time is set based on an event or on polling (don't
know), whether the end time is set at the moment the batch script exits
The sshare reports the same even now (after few hours) - I have not changed
anything after the previous test.
[root@slurm-login slurm-scripts]# sshare
Account User Raw Shares Norm Shares Raw Usage Effectv
Usage FairShare
-- -- --
Hello Mathew,
just to check the basics - did you wait a few minutes before executing sshare?
As far as I remember the RawUsage value is updated every 5 minutes (per
default), so these erroneous values might be caused by a measurement that was
taken while the jobs were still running.
Regards,
On 11/26/2014 04:21 PM, Manuel Rodríguez Pascual wrote:
Hi Ole,
Slurm is not broken, you just have some small configuration issues :)
If you're right, I'd like to add those changes to the SLURM
documentation :-)
Also, if you look at what's going on, it is kind of easy to locate the
proble
sshare doesn't actually have access to the cputime that is accounted
for. All sacct does is (elapsed time * CPU count), something that you
can check in the manpage or sshare code. This can be slightly different
than what was actually accounted for in _apply_new_usage(). Slurm
doesn't do very
Hi Ole,
Slurm is not broken, you just have some small configuration issues :)
Also, if you look at what's going on, it is kind of easy to locate the
problems. For example, task 1.1 fails because executing "id" on you local
resource and the remote one does not return the same result. If you look a
Hi,
Can anyone help in getting SLURM 14.11 to work correctly on CentOS 7.0?
I'm testing SLURM 14.11 on CentOS 7.0. The default SLURM RPM is built
by: rpmbuild -ta slurm-14.11.0.tar.bz2. As a bare minimum test cluster,
I have a master PC running slurmctld, and just 1 compute node PC running
My fairshare test scenario - As it stand the farishare is not distributed
correctly
*Accounts*
[root@slurm-login slurm-scripts]# sacctmgr list accounts
AccountDescr Org
--
premium1 primary account
13 matches
Mail list logo
