Known issues: Difference between revisions

Jump to navigation Jump to search
no edit summary
(Marked this version for translation)
No edit summary
Line 13: Line 13:
** Memory shortage can cause the kernel to kill processes ("OOM kill"), which results in the same message but affects exit status differently.
** Memory shortage can cause the kernel to kill processes ("OOM kill"), which results in the same message but affects exit status differently.
** A job that reports DerivedExitStatus 0:125 indicates hitting the memory limit, but not being OOM-killed.
** A job that reports DerivedExitStatus 0:125 indicates hitting the memory limit, but not being OOM-killed.
** In the absence of any other action, a step with 0:125 will *not* enable a job which has afterok dependency.  This is a Slurm bug that will be [https://bugs.schedmd.com/show_bug.cgi?id=3820 fixed in 17.11.3], so that Slurm can distinguish between the warning condition versus actual kernel OOM-kill events.  Slurm will continue to limit memory usage from cgroups, so I/O memory will still be counted and be reported when exceeds the job's requested memory.
** In the absence of any other action, a step with 0:125 will *not* enable a job which has afterok dependency.  This is a Slurm bug that will be [https://bugs.schedmd.com/show_bug.cgi?id=3820 fixed in 17.11.3], so that Slurm can distinguish between the warning condition versus actual kernel OOM-kill events.  Slurm will continue to limit memory usage from cgroups, so I/O memory will still be counted and be reported when it exceeds the job's requested memory.


<!--T:14-->
<!--T:14-->
* The CC Slurm configuration encourages whole-node jobs. When appropriate, users should request whole-node rather than per-core resources. See [[Job_scheduling_policies#Whole_nodes_versus_cores;|Job Scheduling - Whole Node Scheduling]].
* The CC Slurm configuration encourages whole-node jobs. When appropriate, users should request whole-node rather than per-core resources. Read about [[Job_scheduling_policies#Whole_nodes_versus_cores|whole node scheduling]].
* By default, the job receives environment settings from the submitting shell. This can lead to irreproducible results if it's not what you expect. To force the job to run with a fresh-like login environment, you can submit with <tt>--export=none</tt> or add <tt>#SBATCH --export=NONE</tt> to your job script.
* By default, the job receives environment settings from the submitting shell. This can lead to irreproducible results if it's not what you expect. To force the job to run with a fresh-like login environment, you can submit with <tt>--export=none</tt> or add <tt>#SBATCH --export=NONE</tt> to your job script.


rsnt_translations
56,420

edits

Navigation menu