1COMPLEX(5) Grid Engine File Formats COMPLEX(5)
2
6 complex - Grid Engine complexes configuration file format
7
9 Complex reflects the format of the Grid Engine complex configuration.
10 The definition of complex attributes provides all pertinent information
11 concerning the resource attributes a user may request for a Grid Engine
12 job via the qsub(1) -l option and for the interpretation of these
13 parameters within the Grid Engine system.
14 The Grid Engine complex object defines all entries which are used for
16 configuring the global, the host, and queue object. The system has a
17 set of pre defined entries, which are assigned to a host or queue per
18 default. In a addition can the user define new entries and assign them
19 to one or multiple objects. Each load value has to have its correspond‐
20 ing complex entry object, which defines the type and the relational
21 operator for it.
22 defining resource attributes
24 The complex configuration should not be accessed directly. In order to
25 add or modify complex entries, the qconf(1) options -Mc and -mc should
26 be used instead. While the -Mc option takes a complex configuration
27 file as an argument and overrides the current configuration, the -mc
28 option bring up an editor filled in with the current complex configura‐
29 tion.
30 The provided list contains all definitions of resource attributes in
32 the system. Adding a new entry means to provide: name, shortcut, type,
33 relop, requestable, consumable, default, and urgency. The fields are
34 described below. Changing one is easily done by updating the field to
35 change and removing an entry by deleting its definition. An attribute
36 can only be removed, when it is not referenced in a host or queue
37 object anymore. Also does the system have a set of default resource
38 attributes which are always attached to a host or queue. They cannot be
39 deleted nor can the type of such an attribute be changed.
40 working with resource attributes
42 Before a user can request a resource attribute it has to be attached to
43 the global, host, or cqueue object. The resource attribute exists only
44 for the objects, it got attached to ( if it is attached to the global
45 object(qconf -me global), it exits system wide, host object: only on
46 that host (qconf -me NAME): cqueue object: only on that cqueue (qconf
47 -mq NAME)).
48 When the user attached a resource attribute to an object, one also has
50 to assign a value to it; the resource limit. Another way to get a
51 resource attribute value is done by configuring a load sensor for that
52 attribute.
53 Default queue resource attributes
55 In its default form it contains a selection of parameters in the queue
56 configuration as defined in queue_conf(5). The queue configuration
57 parameters being requestable for a job by the user in principal are:
58 qname
60 hostname
61 notify
62 calendar
63 min_cpu_interval
64 tmpdir
65 seq_no
66 s_rt
67 h_rt
68 s_cpu
69 h_cpu
70 s_data
71 h_data
72 s_stack
73 h_stack
74 s_core
75 h_core
76 s_rss
77 h_rss
78 Default host resource attributes
80 The standard set of host related attributes consists of two categories.
81 he first category is built by several queue configuration attributes
82 which are particularly suitable to be managed on a host basis. These
83 attributes are:
84 slots
86 s_vmem
87 h_vmem
88 s_fsize
89 h_fsize
90 (please refer to queue_conf(5) for details).
91 Note: Defining these attributes in the host complex is no contradiction
93 to having them also in the queue configuration. It allows maintaining
94 the corresponding resources on a host level and at the same time on a
95 queue level. Total virtual free memory (h_vmem) can be managed for a
96 host, for example, and a subset of the total amount can be associated
97 with a queue on that host.
98 The second attribute category in the standard host complex are the
100 default load values Every ge_execd(8) periodically reports load to
101 ge_qmaster(8). The reported load values are either the standard Grid
102 Engine load values such as the CPU load average (see uptime(1)) or load
103 values defined by the Grid Engine administration (see the load_sensor
104 parameter in the cluster configuration ge_conf(5) and the Grid Engine
105 Installation and Administration Guide for details). The characteris‐
106 tics definition for the standard load values is part of the default
107 host complex, while administrator defined load values require extension
108 of the host complex. Please refer to the file <ge_root>/doc/load_param‐
109 eters.asc for detailed information on the standard set of load values.
110 Overriding attributes
112 One attribute can be assigned to the global object, host object, and
113 queue object at the same time. On the host level it might get its value
114 from the user defined resource limit and a load sensor. In case that
115 the attribute is a consumable, we have in addition to the resource
116 limit and its load report on host level also the internal usage, which
117 the system keeps track of. The merge is done as follows:
118 In general an attribute can be overridden on a lower level
120 - global by hosts and queues
121 - hosts by queues and load values or resource limits on the same
122 level.
123 We have one limitation for overriding attributes based on its rela‐
125 tional operator:
126 !=, == operators can only be overridden on the same level, but not on a
128 lower level. The user defined value always overrides the load value.
129 >=, >, <=, < operators can only be overridden, when the new value is
131 more restrictive than the old one.
132 In the case of a consumable on host level, which has also a load sen‐
134 sor, the system checks for the current usage, and if the internal
135 accounting is more restrictive than the load sensor report, the inter‐
136 nal value is kept; if the load sensor report is more restrictive, that
137 one is kept.
138 Note, Grid Engine allows backslashes (\) be used to escape newline
140 (\newline) characters. The backslash and the newline are replaced with
141 a space (" ") character before any interpretation.
142
144 The principal format of a complex configuration is that of a tabulated
145 list. Each line starting with a '#' character is a comment line. Each
146 line despite comment lines define one element of the complex. A element
147 definition line consists of the following 8 column entries per line (in
148 the order of appearance):
149 name
151 The name of the complex element to be used to request this attribute
152 for a job in the qsub(1) -l option. A complex attribute name (see com‐
153 plex_name in sge_types(1)) may appear only once across all complexes,
154 i.e. the complex attribute definition is unique.
155 shortcut
157 A shortcut for name which may also be used to request this attribute
158 for a job in the qsub(1) -l option. An attribute shortcut may appear
159 only once across all complexes, so as to avoid the possibility of
160 ambiguous complex attribute references.
161 type
163 This setting determines how the corresponding values are to be treated
164 Grid Engine internally in case of comparisons or in case of load scal‐
165 ing for the load complex entries:
166 · With INT only raw integers are allowed.
168 · With DOUBLE floating point numbers in double precision (decimal and
170 scientific notation) can be specified.
171 · With TIME time specifiers are allowed. Refer to queue_conf(5) for a
173 format description.
174 · With MEMORY memory size specifiers are allowed. Refer to
176 queue_conf(5) for a format description.
177 · With BOOL the strings TRUE and FALSE are allowed. When used in a
179 load formula (refer to sched_conf(5) ) TRUE and FALSE get mapped
180 into '1' and '0'.
181 · With STRING all strings are allowed and is used for wildcard regular
183 boolean expression matching. Please see sge_types(1) manpage for
184 expression definition.
185 Examples:
187 -l arch="*x24*|sol*" :
188 results in "arch=lx24-x86" OR "arch=lx24-amd64"
189 OR "arch=sol-sparc" OR "arch=sol-sparc64"
190 OR "arch=sol-x86" OR ...
191 -l arch="sol-x??" :
192 results in "arch=sol-x86" OR "arch=sol-x64" OR ...
193 -l arch="lx2[246]-x86" :
194 results in "arch=lx22-x86" OR "arch=lx24-x86"
195 OR "arch=lx26-x86"
196 -l arch="lx2[4-6]-x86" :
197 results in "arch=lx24-x86" OR "arch=lx25-x86"
198 OR "arch=lx26-x86"
199 -l arch="lx2[24-6]-x86" :
200 results in "arch=lx22-x86" OR "arch=lx24-x86"
201 OR "arch=lx25-x86" OR "arch=lx26-x86"
202 -l arch="!lx24-x86&!sol-sparc" :
203 results in NEITHER "arch=lx24-x86" NOR "arch=sol-sparc"
204 -l arch="lx2[4|6]-x86" :
205 results in "arch=lx2[4" OR "arch=6"
206 · CSTRING is like STRING except comparisons are case insensitive.
209 · RESTRING is like STRING and it will be deprecated in the future.
211 · HOST is like CSTRING but the expression must match a valid hostname.
213 relop
215 The relation operator. The relation operator is used when the value
216 requested by the user for this parameter is compared against the corre‐
217 sponding value configured for the considered queues. If the result of
218 the comparison is false, the job cannot run in this queue. Possible
219 relation operators are "==", "<", ">", "<=", ">=" and "EXCL". The only
220 valid operator for string type attributes is "==".
221 The "EXCL" relation operator implements exclusive scheduling and is
223 only valid for consumable boolean type attributes. Exclusive means the
224 result of the comparison is only true if a job requests to be exclusive
225 and no other exclusive or non-exclusive jobs uses the complex. If the
226 job does not request to be exclusive and no other exclusive job uses
227 the complex the comparison is also true.
228 requestable
230 The entry can be used in a qsub(1) resource request if this field is
231 set to 'y' or 'yes'. If set to 'n' or 'no' this entry cannot be used
232 by a user in order to request a queue or a class of queues. If the
233 entry is set to 'forced' or 'f' the attribute has to be requested by a
234 job or it is rejected.
235 To enable resource request enforcement the existence of the resource
237 has to be defined. This can be done on a cluster global, per host and
238 per queue basis. The definition of resource availability is performed
239 with the complex_values entry in host_conf(5) and queue_conf(5).
240 consumable
242 The consumable parameter can be set to either 'yes' ('y' abbreviated),
243 'no' ('n') or 'JOB' ('j'). It can be set to 'yes' and 'JOB' only for
244 numeric attributes (INT, DOUBLE, MEMORY, TIME - see type above). If set
245 to 'yes' or 'JOB' the consumption of the corresponding resource can be
246 managed by Grid Engine internal bookkeeping. In this case Grid Engine
247 accounts for the consumption of this resource for all running jobs and
248 ensures that jobs are only dispatched if the Grid Engine internal book‐
249 keeping indicates enough available consumable resources. Consumables
250 are an efficient means to manage limited resources such a available
251 memory, free space on a file system, network bandwidth or floating
252 software licenses.
253 A consumable defined by 'y' is a per slot consumables which means the
255 limit is multiplied by the number of slots being used by the job before
256 being applied. In case of 'j' the consumable is a per job consumable.
257 This resource is debited as requested (without multiplication) from the
258 allocated master queue. The resource needs not be available for the
259 slave task queues.
260 Consumables can be combined with default or user defined load parame‐
262 ters (see ge_conf(5) and host_conf(5)), i.e. load values can be
263 reported for consumable attributes or the consumable flag can be set
264 for load attributes. The Grid Engine consumable resource management
265 takes both the load (measuring availability of the resource) and the
266 internal bookkeeping into account in this case, and makes sure that
267 neither of both exceeds a given limit.
268 To enable consumable resource management the basic availability of a
270 resource has to be defined. This can be done on a cluster global, per
271 host and per queue basis while these categories may supersede each
272 other in the given order (i.e. a host can restrict availability of a
273 cluster resource and a queue can restrict host and cluster resources).
274 The definition of resource availability is performed with the com‐
275 plex_values entry in host_conf(5) and queue_conf(5). The complex_val‐
276 ues definition of the "global" host specifies cluster global consumable
277 settings. To each consumable complex attribute in a complex_values list
278 a value is assigned which denotes the maximum available amount for that
279 resource. The internal bookkeeping will subtract from this total the
280 assumed resource consumption by all running jobs as expressed through
281 the jobs' resource requests.
282 Note: Jobs can be forced to request a resource and thus to specify
284 their assumed consumption via the 'force' value of the requestable
285 parameter (see above).
286 Note also: A default resource consumption value can be pre-defined by
288 the administrator for consumable attributes not explicitly requested by
289 the job (see the default parameter below). This is meaningful only if
290 requesting the attribute is not enforced as explained above.
291 See the Grid Engine Installation and Administration Guide for examples
293 on the usage of the consumable resources facility.
294 default
296 Meaningful only for consumable complex attributes (see consumable
297 parameter above). Grid Engine assumes the resource amount denoted in
298 the default parameter implicitly to be consumed by jobs being dis‐
299 patched to a host or queue managing the consumable attribute. Jobs
300 explicitly requesting the attribute via the -l option to qsub(1) over‐
301 ride this default value.
302 urgency
304 The urgency value allows influencing job priorities on a per resource
305 base. The urgency value effects the addend for each resource when
306 determining the resource request related urgency contribution. For
307 numeric type resource requests the addend is the product of the urgency
308 value, the jobs assumed slot allocation and the per slot request as
309 specified via -l option to qsub(1). For string type requests the
310 resources urgency value is directly used as addend. Urgency values are
311 of type real. See under sge_priority(5) for an overview on job priori‐
312 ties.
313
315 ge_intro(1), ge_types(1), qconf(1), qsub(1), uptime(1), host_conf(5),
316 queue_conf(5), ge_execd(8), ge_qmaster(8)
317 Grid Engine Installation and Administration Guide.
318
320 See ge_intro(1) for a full statement of rights and permissions.
321GE 6.2u5 $Date: 2009/05/28 16:56:19 $ COMPLEX(5)