Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
S
Slurm
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package Registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
tud-zih-energy
Slurm
Commits
299af662
Commit
299af662
authored
13 years ago
by
Moe Jette
Browse files
Options
Downloads
Patches
Plain Diff
Refactor accounting documentation
parent
b5dff73f
No related branches found
No related tags found
No related merge requests found
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
doc/html/accounting.shtml
+8
-11
8 additions, 11 deletions
doc/html/accounting.shtml
doc/html/resource_limits.shtml
+39
-42
39 additions, 42 deletions
doc/html/resource_limits.shtml
with
47 additions
and
53 deletions
doc/html/accounting.shtml
+
8
−
11
View file @
299af662
<!--#include virtual="header.txt"-->
<h1>Accounting</h1>
<p>NOTE: This documents accounting features available in SLURM version
1.3, which are far more extensive than those available in previous
releases.</p>
<h1>Accounting and Resource Limits</h1>
<p>SLURM can be configured to collect accounting information for every
job and job step executed.
...
...
@@ -386,7 +382,7 @@ make sure the StorageUser is given permissions in MySQL to do so.
As the <i>mysql</i> user grant privileges to that user using a
command such as:</p>
<p>GRANT ALL ON StorageLoc.* TO 'StorageUser'@'StorageHost';
<p>GRANT ALL ON StorageLoc.* TO 'StorageUser'@'StorageHost';
<br>
(The ticks are needed)</p>
<p>(You need to be root to do this. Also in the info for password
...
...
@@ -394,7 +390,7 @@ usage there is a line that starts with '->'. This a continuation
prompt since the previous mysql statement did not end with a ';'. It
assumes that you wish to input more info.)</p>
<p>
l
ive example:</p>
<p>
L
ive example:</p>
<pre>
mysql@snowflake:~$ mysql
...
...
@@ -664,8 +660,10 @@ If a user has a limit set SLURM will read in those,
if not we will refer to the account associated with the job.
If the account doesn't have the limit set we will refer to
the cluster's limits.
If the cluster doesn't have the limit set no limit will be enforced.
<p>All of the above entities can include limits as described below...
If the cluster doesn't have the limit set no limit will be enforced.</p>
<p>All of the above entities can include limits as described below and
in the <a href="resource_limits.html">Resource Limits</a> document.</p>
<ul>
...
...
@@ -673,7 +671,6 @@ If the cluster doesn't have the limit set no limit will be enforced.
Essentially this is the amount of claim this association and it's
children have to the above system. Can also be the string "parent",
this means that the parent association is used for fairshare.
</li>
</li>
<li><b>GrpCPUMins=</b> A hard limit of cpu minutes to be used by jobs
...
...
@@ -780,7 +777,7 @@ as deleted.
If an entity has existed for less than 1 day, the entity will be removed
completely. This is meant to clean up after typographic errors.</p>
<p style="text-align: center;">Last modified
27 January
2010</p>
<p style="text-align: center;">Last modified
10 June
2010</p>
<!--#include virtual="footer.txt"-->
This diff is collapsed.
Click to expand it.
doc/html/resource_limits.shtml
+
39
−
42
View file @
299af662
...
...
@@ -63,7 +63,8 @@ each association in the database. By setting this option, the
set to true.
</li>
</ul>
(NOTE: The association is a combination of cluster, account,
<p>(NOTE: The association is a combination of cluster, account,
user names and optional partition name.)
<br>
Without AccountingStorageEnforce being set (the default behavior)
...
...
@@ -72,7 +73,7 @@ cluster.
<br>
It is advisable to run without the option 'limits' set when running a
scheduler on top of SLURM, like Moab, that does not update in real
time their limits per association.
</li>
time their limits per association.
</p>
<h2>Tools</h2>
...
...
@@ -108,40 +109,23 @@ specified then no limit will apply.</p>
<p>Currently available scheduling policy options:</p>
<ul>
<li><b>Fairshare=</b> Used for determining priority. Essentially
this is the amount of claim this association and it's children have
to the above system.</li>
<li><b>Fairshare=</b> Integer value used for determining priority.
Essentially this is the amount of claim this association and it's
children have to the above system. Can also be the string "parent",
this means that the parent association is used for fairshare.
</li>
<!-- For future use
<li><b>GrpCPUMins=</b> A hard limit of cpu minutes to be used by jobs
running from this association and its children. If this limit is
reached all jobs running in this group will be killed, and no new
jobs will be allowed to run.
</li>
-->
<!-- For future use
<li><b>MaxCPUMinsPerJob=</b> A limit of cpu minutes to be used by jobs
running from this association. If this limit is
reached the job will be killed will be allowed to run.
</li>
-->
<!-- For future use
<li><b>GrpCPUs=</b> The total count of cpus able to be used at any given
time from jobs running from this association and its children. If
this limit is reached new jobs will be queued but only allowed to
run after resources have been relinquished from this group.
</li>
-->
<!-- For future use
<li><b>MaxCPUsPerJob=</b> The maximum size in cpus any given job can
have from this association. If this limit is reached the job will
be denied at submission.
</li>
-->
<li><b>GrpJobs=</b> The total number of jobs able to run at any given
time from this association and its children. If
...
...
@@ -149,48 +133,61 @@ specified then no limit will apply.</p>
run after previous jobs complete from this group.
</li>
<li><b>MaxJobs=</b> The total number of jobs able to run at any given
time from this association. If this limit is reached new jobs will
be queued but only allowed to run after previous jobs complete from
this association.
</li>
<li><b>GrpNodes=</b> The total count of nodes able to be used at any given
time from jobs running from this association and its children. If
this limit is reached new jobs will be queued but only allowed to
run after resources have been relinquished from this group.
</li>
<li><b>MaxNodesPerJob=</b> The maximum size in nodes any given job can
have from this association. If this limit is reached the job will
be denied at submission.
</li>
<li><b>GrpSubmitJobs=</b> The total number of jobs able to be submitted
to the system at any given time from this association and its children. If
this limit is reached new submission requests will be denied until
previous jobs complete from this group.
</li>
<li><b>GrpWall=</b> The maximum wall clock time any job submitted to
this group can run for. If this limit is reached submission requests
will be denied.
</li>
<li><b>MaxCPUsPerJob=</b> The maximum size in cpus any given job can
have from this association. If this limit is reached the job will
be denied at submission.
</li>
<li><b>MaxJobs=</b> The total number of jobs able to run at any given
time from this association. If this limit is reached new jobs will
be queued but only allowed to run after previous jobs complete from
this association.
</li>
<li><b>MaxNodesPerJob=</b> The maximum size in nodes any given job can
have from this association. If this limit is reached the job will
be denied at submission.
</li>
<li><b>MaxSubmitJobs=</b> The maximum number of jobs able to be submitted
to the system at any given time from this association. If
this limit is reached new submission requests will be denied until
previous jobs complete from this association.
</li>
<li><b>GrpWall=</b> The maximum wall clock time any job submitted to
this group can run for. Submitting jobs that specify a wall clock
time limit that exceeds this limit will be denied.</li>
<li><b>MaxWallDurationPerJob=</b> The maximum wall clock time any job
submitted to this association can run for. Submitting jobs that
specify a wall clock time limit that exceeds this limit will be
denied.
submitted to this association can run for. If this limit is reached
the job will be denied at submission.
</li>
<li><b>QOS=</b> comma separated list of QOS's this association is
able to run.
</li>
<!-- For future use
<li><b>MaxCPUMinsPerJob=</b> A limit of cpu minutes to be used by jobs
running from this association. If this limit is
reached the job will be killed will be allowed to run.
</li>
-->
</ul>
<p>The <b>MaxNodes</b> and <b>MaxWall</b> options already exist in
...
...
@@ -205,6 +202,6 @@ data maintained in the SLURM database. More information can be found
in the <a href="priority_multifactor.html">priority/multifactor</a>
plugin description.</p>
<p style="text-align: center;">Last modified
9 October
20
09
</p>
<p style="text-align: center;">Last modified
10 June
20
11
</p>
</ul></body></html>
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment