From 299af66273d43907024adbe0eaec7ce99c74e0e7 Mon Sep 17 00:00:00 2001 From: Moe Jette <jette1@llnl.gov> Date: Fri, 10 Jun 2011 15:42:37 -0700 Subject: [PATCH] Refactor accounting documentation --- doc/html/accounting.shtml | 19 ++++---- doc/html/resource_limits.shtml | 81 ++++++++++++++++------------------ 2 files changed, 47 insertions(+), 53 deletions(-) diff --git a/doc/html/accounting.shtml b/doc/html/accounting.shtml index 887f4c2d0ed..3391be7e5c3 100644 --- a/doc/html/accounting.shtml +++ b/doc/html/accounting.shtml @@ -1,10 +1,6 @@ <!--#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>live example:</p> +<p>Live 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"--> diff --git a/doc/html/resource_limits.shtml b/doc/html/resource_limits.shtml index c2f1b21cf94..49f75922efc 100644 --- a/doc/html/resource_limits.shtml +++ b/doc/html/resource_limits.shtml @@ -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 2009</p> +<p style="text-align: center;">Last modified 10 June 2011</p> </ul></body></html> -- GitLab