307 lines
8.1 KiB
Groff
307 lines
8.1 KiB
Groff
.TH miser 4
|
|
.SH NAME
|
|
\f3miser\f1 \- configuration files
|
|
.SH DESCRIPTION
|
|
The configuration of the
|
|
.I miser(1)
|
|
Queues defines the resources allocated to the miser system. The
|
|
configuration of
|
|
.I miser(1)
|
|
involves two steps. The first is to enumerate all the queues that will
|
|
be part of the
|
|
.I miser(1)
|
|
system, and the second is to define the queues. The enumeration of
|
|
the queues is done in the miser configuration file. The definition of
|
|
the queues is done in the queue definition files.
|
|
.P
|
|
Each
|
|
.I miser(1)
|
|
system requires that a system queue be defined. The system queue definition
|
|
defines the maximum resources available to any other queue's definition.
|
|
.SH MISER CONFIGURATION FILE
|
|
The miser configuration file is a list of the queue names and the location
|
|
of each queue definition file.
|
|
.TP
|
|
.SH EXAMPLE
|
|
.nf
|
|
\f3
|
|
QUEUE system /usr/local/miser/config.system
|
|
QUEUE physics /usr/local/miser/config.physics
|
|
\f1
|
|
.SH SUMMARY
|
|
.P
|
|
Each miser configuration file must include a definition for the system
|
|
queue. The system queue is identified by the queue name "system".
|
|
.P
|
|
Commands are newline terminated, characters following the comment delimiter
|
|
are '#' are ignored, and case matters.
|
|
.P
|
|
The valid tokens are:
|
|
.TP
|
|
.BR QUEUE " [qname] " " [file pathname] "
|
|
The queue name is used to identify the queue when using any interface to
|
|
miser. The queue name must be between 1 and 8 characters long. The queue
|
|
name
|
|
.I system
|
|
is used to designate the system queue.
|
|
.SH QUEUE DEFINITION FILE
|
|
The queue definition file consists of a header specifying the policy of the
|
|
queue, the number of resource segments, and the quantum used by the queue.
|
|
If the quantum of any queue is different from the system queue quantum, the
|
|
queue definition file is rejected.
|
|
.SH EXAMPLE
|
|
.nf
|
|
\f3
|
|
# This queue definition file defines a queue using the policy
|
|
# named "default", has a quantum of 20 seconds, and has 3
|
|
# elements to the vector definition. The start and end times
|
|
# of each tuple are in quanta not in seconds. The first segment
|
|
# defines a resource tuple beginning at 00:00 and ending at
|
|
# 00:50 with 50 CPUs and 100 megabytes of memory. The second
|
|
# segment defines a resource tuple beginning 00:51.67 and ending
|
|
# at 01:00 with 50 CPUs and 100 megabytes. The third segment
|
|
# defines a resource tuple begining at 01:02.00 and ending at
|
|
# 01:03.33 also with 50 CPUs and 100 megabytes of memory.
|
|
|
|
POLICY default
|
|
QUANTUM 20
|
|
NSEG 3
|
|
|
|
SEGMENT
|
|
NCPUS 50
|
|
MEMORY 100m
|
|
START 0
|
|
END 150
|
|
|
|
SEGMENT
|
|
NCPUS 50
|
|
MEMORY 100m
|
|
START 155
|
|
END 185
|
|
|
|
SEGMENT
|
|
NCPUS 50
|
|
MEMORY 100m
|
|
START 186
|
|
END 190
|
|
\f1
|
|
.f1
|
|
.SH SUMMARY
|
|
.P
|
|
Commands are newline terminated, characters following the comment delimiter
|
|
are '#' are ignored, and case matters.
|
|
.P
|
|
Each new segment must begin with the token SEGMENT and must have the number
|
|
of CPUs, memory and wall clock time specified at a minimum.
|
|
.P
|
|
The valid tokens are
|
|
.TP
|
|
.BR POLICY " name "
|
|
The name of the policy that will be used to schedule applications submitted
|
|
to the queue. Currently, the two valid policies are: "default", and "repack".
|
|
The "default policy is the first fit policy, where once a job is scheduled,
|
|
its start and end time remains constant. Each time any job ends on a queue
|
|
with a "repack" policy the entire job schedule is reevaluated and updated.
|
|
When machine resources are freed due an executing job's early termination,
|
|
the repack policy will attempt to reschedule queued jobs, pulling them ahead
|
|
in time. While repacking endeavors to maintain the FIFO order of queued jobs,
|
|
a higher priority is given to the optimal utilization of machine resources.
|
|
The actual start and end times of a job in a queue with a repack policy can
|
|
potentially be earlier than its initially reported start and end times. See
|
|
.I miser(5).
|
|
.TP
|
|
.BR QUANTUM " time "
|
|
The size of the quantum. The time is specified in seconds.
|
|
.TP
|
|
.BR NSEG " number "
|
|
The number of resource segments.
|
|
.TP
|
|
.BR SEGMENT
|
|
Defines the beginning of a new segment of the vector definition.
|
|
.TP
|
|
.BR START " number of quanta from 0 "
|
|
The number of quanta from 0 (defined to be CTU) that the segment begins at.
|
|
.TP
|
|
.BR END " number of quanta from 0 "
|
|
The number of quanta from 0 (defined to be CTU) that the segment ends at.
|
|
.P
|
|
The maximum acceptable END value is 259200. This represents a possible
|
|
maximum run length of two months with a 20 second quantum size
|
|
((2 months * 30 days * 24 hours * 60 minutes * 60 seconds) / 20 seconds).
|
|
The effective maximum queue duration can be increased beyond two months
|
|
by increasing the quantum size.
|
|
.TP
|
|
.BR NCPUS " number of CPUs "
|
|
The number of CPUs.
|
|
.TP
|
|
.BR MEMORY " amount of memory "
|
|
The amount of memory, specified by an integer followed by an optional unit of
|
|
.I k
|
|
for kilobyte,
|
|
.I m
|
|
for megabyte, and
|
|
.I g
|
|
for gigabyte. If no unit is specified then the value is treated as byte.
|
|
.P
|
|
For all the examples, the machine has 12 CPUs and 160MB memory.
|
|
.P
|
|
EXAMPLE 1: A machine dedicated to batch scheduling with one queue,
|
|
24 hours a day.
|
|
.P
|
|
First System Queue must be defined. The length of the system queue defines
|
|
the maximum duration of any job submitted to the system. For this system the
|
|
maximum duration for any one job can be 48 hours, so the system vector is
|
|
defined to have a duration of 48 hours.
|
|
.nf
|
|
\f3
|
|
# The system queue /usr/local/miser/system
|
|
POLICY none # System queue has no policy
|
|
QUANTUM 20 # Default quantum set to 20 seconds
|
|
NSEG 1
|
|
|
|
SEGMENT
|
|
NCPUS 12
|
|
MEMORY 160m
|
|
START 0
|
|
END 8640 # Number of quanta (48h * 60m * 60s / 20)
|
|
\f1
|
|
.f1
|
|
.P
|
|
Next a user queue needs to be defined.
|
|
.nf
|
|
\f3
|
|
# The user queue /usr/local/miser/physics
|
|
POLICY default # First fit, once scheduled maintains start/end time
|
|
QUANTUM 20 # Default quantum set to 20 seconds
|
|
NSEG 1
|
|
|
|
SEGMENT
|
|
NCPUS 12
|
|
MEMORY 160m
|
|
START 0
|
|
END 8640 # Number of quanta (48h * 60m * 60s / 20)
|
|
\f1
|
|
.f1
|
|
.P
|
|
Finally a miser configuration file must be created.
|
|
.nf
|
|
\f3
|
|
# MISER config file
|
|
QUEUE system /usr/local/miser/system
|
|
QUEUE physics /usr/local/miser/physics
|
|
\f1
|
|
.f1
|
|
EXAMPLE 2: A machine dedicated to batch scheduling, 24 hours a day
|
|
and is shared between two user groups.
|
|
.P
|
|
Suppose we have 2 user groups, chemistry and physics. Suppose the
|
|
machine must be divided between them, in a ratio of 66% for physics and
|
|
33% for chemistry.
|
|
.P
|
|
The system queue is identical to the one in EXAMPLE 1.
|
|
.nf
|
|
\f3
|
|
# The physics queue /usr/local/miser/physics
|
|
POLICY default
|
|
QUANTUM 20i
|
|
NSEG 1
|
|
|
|
SEGMENT
|
|
NCPUS 8
|
|
MEMORY 120m
|
|
START 0
|
|
END 8640 # Number of quanta (48h * 60m * 60s / 20)
|
|
\f1
|
|
.f1
|
|
.P
|
|
Now the chemistry queue:
|
|
.nf
|
|
\f3
|
|
# The chemistry queue /usr/local/miser/chemistry
|
|
POLICY default
|
|
QUANTUM 20
|
|
NSEG 1
|
|
|
|
SEGMENT
|
|
NCPUS 4
|
|
MEMORY 40m
|
|
START 0
|
|
END 8640 # Number of quanta (48h * 60m * 60s / 20)
|
|
\f1
|
|
.f1
|
|
.P
|
|
To restrict access to each queue, the user groups physics and
|
|
chemistry are created. The permissions on the physics queue definition
|
|
file are set to execute ONLY for group physics and the permissions on
|
|
the chemistry queue definition are set to execute only for group
|
|
chemistry.
|
|
.P
|
|
Finally, the miser configuration file must be created:
|
|
.nf
|
|
\f3
|
|
# MISER configuration file
|
|
QUEUE system /usr/local/miser/system
|
|
QUEUE physics /usr/local/miser/physics
|
|
QUEUE chem /usr/local/miser/chemistry
|
|
\f1
|
|
.f1
|
|
.P
|
|
EXAMPLE 3: The machine is dedicated to TS in the morning but to
|
|
batch in the evening. The evening is 8pm - 4am and the morning is
|
|
4am to 8pm.
|
|
.P
|
|
This is the same example discussed in
|
|
.I miser(1).
|
|
.P
|
|
First the system queue is defined.
|
|
.nf
|
|
\f3
|
|
# System queue
|
|
POLICY none # System queue has no policy
|
|
QUANTUM 20 # Default quantum set to 20 seconds
|
|
NSEG 2
|
|
|
|
SEGMENT
|
|
NCPUS 12
|
|
MEMORY 160
|
|
START 0
|
|
END 720 # (4h * 60m * 60s) / 20
|
|
|
|
SEGMENT
|
|
NCPUS 12
|
|
MEMORY 160
|
|
START 3600 # 8pm is 20hours from CTU, so (20h * 60m * 60s) / 20
|
|
END 4320
|
|
\f1
|
|
.f1
|
|
.P
|
|
Next, the batch queue is defined.
|
|
.nf
|
|
\f3
|
|
# User queue
|
|
POLICY repack # Repacks jobs (FIFO) if a job finishes early
|
|
QUANTUM 20 # Default quantum set to 20 seconds
|
|
NSEG 2
|
|
|
|
SEGMENT
|
|
NCPUS 12
|
|
MEMORY 160
|
|
START 0
|
|
END 720 # (4h * 60m * 60s) / 20
|
|
|
|
SEGMENT
|
|
NCPUS 12
|
|
MEMORY 160
|
|
START 3600 # 8pm is 20h from CTU, (20h * 60m * 60s) / 20
|
|
END 4320
|
|
\f1
|
|
.f1
|
|
.SH SEE ALSO
|
|
miser(5),
|
|
miser(1),
|
|
miser_submit(1),
|
|
miser_jinfo(1),
|
|
miser_qinfo(1),
|
|
miser_move(1),
|
|
miser_reset(1).
|