On Friday, 23 February 2018 7:57:54 AM AEDT Christopher Benjamin Coffey wrote:
> Yes, maybe that’s true about what you say when not using srun. I'm not sure,
> as we tell everyone to use srun to launch every type of task.
I've not done that out of habit with users, but it has one really useful si
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
per
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
s
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
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
Howdy,
Yes there is a difference between those two submissions. You are correct that
usually ntasks is for mpi and cpus-per-task is for multithreading, but let’s
look at your commands.
For your first example, the “sbatch --ntasks 24 […]”, this will allocated a job
with 24 tasks. These tasks
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 writes:
At least from
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 -n is for rank based para
Hi, Other Chris,
Christopher Benjamin Coffey writes:
> 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
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 th
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 -n is for rank based parallelism. This
way the thread affin
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 (unco
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 mariadb.
Hi Chris,
we were faced with exactly the same problem - update of 16.05.11 to
17.11.3 took more than 24 hours without finalizing the conversion of job
table. Finally, we cancelled the process, went back to "old" version
16.05.11 and restored the database. At that time we had 10.5 million
jobs
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 Ben
Hi Chris,
Christopher Samuel writes:
> 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 tha
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
betw
17 matches
Mail list logo
