Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "Tools/Manuals/TS190"

From EGIWiki
Jump to navigation Jump to search
(Created page with '{{TOC_right}} Category:FAQ ------ Back to Administration FAQ ------ = How to define values for SI00, HEP-SPEC, MaxCPUTime, MaxWallClockTi…')
 
Line 30: Line 30:
These days it is preferred to derive the value of the
These days it is preferred to derive the value of the
<tt>GlueHostBenchmarkSI00</tt> attribute from an actual measurement
<tt>GlueHostBenchmarkSI00</tt> attribute from an actual measurement
of the <tt>HEP-SPEC06</tt> benchmark on a representative machine,
of the <tt>HEP-SPEC06</tt> benchmark average per core at your site,
published as part of <tt>GlueHostProcessorOtherDescription</tt>,
published as part of <tt>GlueHostProcessorOtherDescription</tt>,
as described here:
as described here:
Line 39: Line 39:


* [https://twiki.cern.ch/twiki/bin/view/LCG/Site-info_configuration_variables#site_info_def YAIM site-info.def variables]
* [https://twiki.cern.ch/twiki/bin/view/LCG/Site-info_configuration_variables#site_info_def YAIM site-info.def variables]
* [https://twiki.cern.ch/twiki/pub/LCG/WLCGCommonComputingReadinessChallenges/WLCG_GlueSchemaUsage-1.8.pdf WLCG GLUE Schema usage]


== Batch system scaling ==
== Batch system scaling ==
Line 45: Line 47:
for a job's maximum CPU and wall-clock time according to the performance
for a job's maximum CPU and wall-clock time according to the performance
of the worker node on which it is running.  In that case the published
of the worker node on which it is running.  In that case the published
<tt>HEP-SPEC06 / SI00 / MaxCPUTime / MaxWallClockTime</tt> values must
<tt>MaxCPUTime / MaxWallClockTime</tt> values must refer to the
refer to the '''reference''' machine (for which the scaling factor is
'''reference''' machine (for which the scaling factor would be exactly one).
exactly one). In other cases they must refer to the '''slowest''' machine
In other cases they must refer to the '''slowest''' machine
in the SubCluster.  If there is a large variety in the performance of
in the SubCluster.  If there is a large variety in the performance of
worker nodes in a particular SubCluster, consider separating them into
worker nodes in a particular SubCluster, consider separating them into
multiple SubClusters in the batch system and configure your CE hosts
multiple SubClusters in the batch system and configure your CE hosts
correspondingly.
correspondingly.
In any case each CE queue needs to publish a <tt>GlueCECapability</tt> that
indicates the power of the reference machine:
* <tt>CPUScalingReferenceSI00=N</tt>
Here <tt>N</tt> is the value of <tt>GlueHostBenchmarkSI00</tt> (see above)
scaled to the reference machine.


== MaxCPUTime and MaxWallClockTime ==
== MaxCPUTime and MaxWallClockTime ==

Revision as of 20:40, 30 September 2011


Back to Administration FAQ


How to define values for SI00, HEP-SPEC, MaxCPUTime, MaxWallClockTime

The GLUE 1.3 schema defines 3 essential objects for computing resources:

  • GlueCE - represents a queue in the batch system
  • GlueCluster - aggregates GlueCE and GlueSubCluster objects
  • GlueSubCluster - represents a disjoint set of sufficiently homogeneous worker nodes

The gLite/EMI WMS currently cannot explicitly direct a job to a particular SubCluster (by forwarding job requirements via the CE to the batch system); therefore one generally is advised to have different SubClusters aggregated by different GlueCluster objects, typically for different CE hosts. In other words, a GlueCE should be associated with a single GlueCluster that is associated with a single GlueSubCluster. A future revision of the EMI WMS is foreseen to allow job requirements to be forwarded at least to CREAM CEs.

For each SubCluster the admin needs to determine reasonably correct values at least for the GlueHostBenchmarkSI00 and GlueHostProcessorOtherDescription attributes: the GlueHostBenchmarkSF00 (sic) attribute is less important and often given a zero value to indicate it has not been determined.

These days it is preferred to derive the value of the GlueHostBenchmarkSI00 attribute from an actual measurement of the HEP-SPEC06 benchmark average per core at your site, published as part of GlueHostProcessorOtherDescription, as described here:

See also:

Batch system scaling

Your batch system may have been configured to scale the values for a job's maximum CPU and wall-clock time according to the performance of the worker node on which it is running. In that case the published MaxCPUTime / MaxWallClockTime values must refer to the reference machine (for which the scaling factor would be exactly one). In other cases they must refer to the slowest machine in the SubCluster. If there is a large variety in the performance of worker nodes in a particular SubCluster, consider separating them into multiple SubClusters in the batch system and configure your CE hosts correspondingly.

In any case each CE queue needs to publish a GlueCECapability that indicates the power of the reference machine:

  • CPUScalingReferenceSI00=N

Here N is the value of GlueHostBenchmarkSI00 (see above) scaled to the reference machine.

MaxCPUTime and MaxWallClockTime

Your batch system may define various queues with different values for the maximum CPU and wall-clock time that apply to the jobs in each queue. The number of queues and their properties are defined per site according to site-specific policies and the needs of the supported communities. A supported VO may negotiate the batch queue properties with the site.

For a particular value of the MaxCPUTime there is no universal recipe to determine a corresponding value for MaxWallClockTime, but here are some considerations:

  • Jobs may occasionally or often need to wait for I/O to complete, depending on the type of job, the VO, concurrent activities, ...
  • The higher the number of concurrent jobs on a worker node or in the batch system, the higher the competition for shared resources:
    • memory
    • cache
    • local disk
    • network
    • storage element
  • A job might get stuck due to a mistake in the job's code or a problem at the site: in those cases it may be counterproductive to allow the job to sit idle and keep its slot occupied for a long time.

To allow for normal I/O wait times, while trying to guard against jobs wasting their slots, in practice the MaxWallClockTime for a particular queue usually is set to 1.5 or 2 times its MaxCPUTime.