diff --git a/docs.it4i/general/capacity-computing.md b/docs.it4i/general/capacity-computing.md index c5e5311466cb404ea6b5a3f4607d0012c41d33a0..10c338d518b674f44049294a285bf17425ddf518 100644 --- a/docs.it4i/general/capacity-computing.md +++ b/docs.it4i/general/capacity-computing.md @@ -2,20 +2,23 @@ ## Introduction -In many cases, it is useful to submit a huge (>100) number of computational jobs into the Slurm queue system. +In many cases, it is useful to submit a huge number of computational jobs into the Slurm queue system. A huge number of (small) jobs is one of the most effective ways to execute embarrassingly parallel calculations, -achieving the best runtime, throughput, and computer utilization. +achieving the best runtime, throughput, and computer utilization. This is called the **Capacity Computing** However, executing a huge number of jobs via the Slurm queue may strain the system. This strain may result in slow response to commands, inefficient scheduling, and overall degradation of performance and user experience for all users. -[//]: # (For this reason, the number of jobs is **limited to 100 jobs per user, 4,000 jobs and subjobs per user, 1,500 subjobs per job array**.) +There are two primary scenarios: -!!! note - Follow one of the procedures below, in case you wish to schedule more than 100 jobs at a time. +1. Numeber of jobs < XXX, the jobs are able to utilize one or more full nodes + Use [Job arrays][2]. -You can use [HyperQueue][1] when running a huge number of jobs. HyperQueue can help efficiently -load balance a large number of jobs amongst available computing nodes. +2. Number of jobs >> XXX, the jobs only utilze few cores. + Use [HyperQueue][1] when running a huge number of jobs. HyperQueue can help efficiently + load balance a large number of jobs amongst available computing nodes. -[1]: hyperqueue.md + +[1]: job-arrays.md +[2]: hyperqueue.md \ No newline at end of file