Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
habrok:job_management:scheduling_system [2026/06/29 12:39] – [Nodes and cores] pedrohabrok:job_management:scheduling_system [2026/08/14 12:39] (current) – [Nodes and cores] pedro
Line 16: Line 16:
 When resources are available jobs will start immediately. If the requested resources are not available jobs will be put in a queue. The ordering of this queue is based on priority. High resource usage will lower your priority for new jobs. A period of low activity will cause your priority for new jobs to increase again.  When resources are available jobs will start immediately. If the requested resources are not available jobs will be put in a queue. The ordering of this queue is based on priority. High resource usage will lower your priority for new jobs. A period of low activity will cause your priority for new jobs to increase again. 
  
-**IMPORTANT** For those that know most of this, or are to lazy to read the whole page there are some [[#guidelines_for_cpu_cores_time_and_memory|important guidelines that you should know]]. +<wrap important>For those that know most of this, or are to lazy to read the whole page there are some [[#guidelines_for_cpu_cores_time_and_memory|important guidelines that you should know]]. </wrap>
  
 ===== SLURM ===== ===== SLURM =====
Line 73: Line 73:
 |''%%--%%cpus-per-task''  |Number of threads per task (for multithreaded applications)                                |1            | |''%%--%%cpus-per-task''  |Number of threads per task (for multithreaded applications)                                |1            |
  
-<wrap important>The numbers that are given here, depend on the capabilities of the program being run. Only for programs that can use multiple CPU cores the number of tasks and/or cpus per task may be set higher than 1. The number of nodes can only be higher than 1 for software that is capable of running on multiple physical computers, using network communication.</wrap>+<wrap info>The numbers that are given here, depend on the capabilities of the program being run.</wrap> Only for programs that can use multiple CPU cores the number of tasks and/or cpus per task may be set higher than 1. The number of nodes can only be higher than 1 for software that is capable of running on multiple physical computers, using network communication.
  
 <WRAP important round center>**VERY IMPORTANT! If you don't know if your program is capable of running in parallel, do not request multiple cores, or nodes! In most cases this is useless and a waste of resources.**</WRAP> <WRAP important round center>**VERY IMPORTANT! If you don't know if your program is capable of running in parallel, do not request multiple cores, or nodes! In most cases this is useless and a waste of resources.**</WRAP>
Line 158: Line 158:
 ===== System limits enforced ===== ===== System limits enforced =====
  
-**IMPORTANT** Each job requests a number of cores and an amount of memory. When the job is running, it will be limited to the amounts requested. This has the following effects, which are important to keep in mind:+<WRAP important round center>**IMPORTANT** Each job requests a number of cores and an amount of memory. When the job is running, it will be limited to the amounts requested.  
 + 
 +This has the following effects, which are important to keep in mind: 
 +</WRAP>
  
   * If your job or application starts more processes than cores are requested, these processes will share the number of requested cores. This does not benefit the performance of your software, but will normally slow it down.   * If your job or application starts more processes than cores are requested, these processes will share the number of requested cores. This does not benefit the performance of your software, but will normally slow it down.
Line 172: Line 175:
 For the first runs you can then use overestimates for the time and memory requirement to make sure your calculations will not be aborted. Once you have gotten feedback from the scheduler about the actual time and memory consumption you can then use more precise amounts. Some hints about reasonable sizes: For the first runs you can then use overestimates for the time and memory requirement to make sure your calculations will not be aborted. Once you have gotten feedback from the scheduler about the actual time and memory consumption you can then use more precise amounts. Some hints about reasonable sizes:
   * The memory on a standard Hábrók node is at least 4GB per core. So memory requests around 4GB are no problem at all.   * The memory on a standard Hábrók node is at least 4GB per core. So memory requests around 4GB are no problem at all.
-  * For memory requests above 4GB/core you should check the job output for the actual memory usage and adjust the number for consecutive runs. **VERY IMPORTANT Please don't request more than 10GB/core when you are not sure that your program needs it!** You are wasting valuable resources others may need if you do. +  * For memory requests above 4GB/core you should check the job output for the actual memory usage and adjust the number for consecutive runs. <wrap important>**VERY IMPORTANT Please don't request more than 10GB/core when you are not sure that your program needs it!**</wrap> You are wasting valuable resources others may need if you do. 
-  * **VERY IMPORTANT Never request more than 1 CPU core if you don't know that your program can actually use multiple cores.** Check the program documentation for information on this.  +  * <wrap important>**VERY IMPORTANT Never request more than 1 CPU core if you don't know that your program can actually use multiple cores.**</wrap> Check the program documentation for information on this. 
-  * **IMPORTANT** When requesting multiple cores check the actual speed gain with respect to runs using fewer cores. Most programs will not scale beyond a certain number of CPU cores or nodes. Runs may not be faster, and again you will just be wasting resources for no increase in time to result. On the other hand you will experience longer waiting times for your jobs.+  * <wrap important>**IMPORTANT** When requesting multiple cores check the actual speed gain with respect to runs using fewer cores.</wrap> Most programs will not scale beyond a certain number of CPU cores or nodes. Runs may not be faster, and again you will just be wasting resources for no increase in time to result. On the other hand you will experience longer waiting times for your jobs.
   * A reasonable time requirement will mainly improve the scheduler performance. Shorter jobs can be more easily scheduled. You will therefore benefit yourself if you don't request long times if you don't need them. There are also limits on the number of very long jobs that are allowed to run in the system simultaneously.   * A reasonable time requirement will mainly improve the scheduler performance. Shorter jobs can be more easily scheduled. You will therefore benefit yourself if you don't request long times if you don't need them. There are also limits on the number of very long jobs that are allowed to run in the system simultaneously.
   *  Smaller (CPU cores & memory) and shorter jobs can be more easily scheduled as fewer resources need to be freed up for them. They may even be squeezed in before large jobs that are waiting for resources to become available.  So it is beneficial to use precise job requirements. But balance this with the fact that running out of memory or time will kill your job.    *  Smaller (CPU cores & memory) and shorter jobs can be more easily scheduled as fewer resources need to be freed up for them. They may even be squeezed in before large jobs that are waiting for resources to become available.  So it is beneficial to use precise job requirements. But balance this with the fact that running out of memory or time will kill your job.