Re: [slurm-users] ntasks and cpus-per-task

On 02/22/2018 07:50 AM, Christopher Benjamin Coffey wrote: It’s a big deal if folks use -n when it’s not an mpi program. This is because the non mpi program is launched n times (instead of once with internal threads) and will stomp over logs and output files (uncoordinated) leading to poor

Re: [slurm-users] Disable Account Limits Per Partition?

John, I'm not sure about accounts but you can do that with users: sacctmgr add user someuser823 account=myaccount7 partition=somepartition You can set different limits for particular partitions (grpsubmit example): sacctmgr modify user someuser823 partition=somepartition set grpsubmit=1 or

Re: [slurm-users] ntasks and cpus-per-task

Hi Loris, "But that's only the case if the program is started with srun or some form of mpirun. Otherwise the program just gets started once on one core and the other cores just idle." Yes, maybe that’s true about what you say when not using srun. I'm not sure, as we tell everyone to

Re: [slurm-users] Extreme long db upgrade 16.05.6 -> 17.11.3

Thanks Paul. I didn't realize we were tracking energy ( . Looks like the best way to stop tracking energy is to specify what you want to track with AccountingStorageTRES ? I'll give that a try. Best, Chris — Christopher Coffey High-Performance Computing Northern Arizona University 928-523-1167

Re: [slurm-users] ntasks and cpus-per-task

Yeah, I've found that in those situations to have people wrap their threaded programs in srun inside of sbatch.  That way the scheduler knows which process specifically gets the threading. -Paul Edmon- On 02/22/2018 10:39 AM, Loris Bennett wrote: Hi Paul, Paul Edmon

Re: [slurm-users] ntasks and cpus-per-task

Hi Paul, Paul Edmon writes: > At least from my experience wonky things can happen with slurm > (especially if you have thread affinity on) if you don't rightly > divide between -n and -c.  In general I've been telling our users that > -c is for threaded applications and

Re: [slurm-users] Extreme long db upgrade 16.05.6 -> 17.11.3

Typically the long db upgrades are only for major version upgrades.  Most of the time minor versions don't take nearly as long. At least with our upgrade from 17.02.9 to 17.11.3 the upgrade only took 1.5 hours with 6 months worth of jobs (about 10 million jobs).  We don't track energy usage

Re: [slurm-users] ntasks and cpus-per-task

Loris, It’s simple, tell folks only to use -n for mpi jobs, and -c otherwise (default). It’s a big deal if folks use -n when it’s not an mpi program. This is because the non mpi program is launched n times (instead of once with internal threads) and will stomp over logs and output files

Re: [slurm-users] Extreme long db upgrade 16.05.6 -> 17.11.3

We experienced the same problem. On our two new clusters with smaller databases (<1 million jobs), the upgrade from 17.02.9 to 17.11.2 and 17.11.3 was quick and smooth. On the third, older cluster, where we have a larger database (>30 million jobs) the upgrade was a mess, both in mysql and

Re: [slurm-users] ntasks and cpus-per-task

Hi, That was just I thought, ntasks for mpi and cpus-per-task for multithreading. So, for example, if every node has 24 cores, is there any difference between these commands? sbatch --ntasks 24 [...] sbatch --ntasks 1 --cpus-per-task 24 [...] regards. El jue., 22 feb. 2018 a las 9:52, Loris

Re: [slurm-users] ntasks and cpus-per-task

On 22/02/18 18:49, Miguel Gutiérrez Páez wrote: What's the real meaning of ntasks? Has cpus-per-task and ntasks the same meaning in sbatch and srun? --ntasks is for parallel distributed jobs, where you can run lots of independent processes that collaborate using some form of communication