没有合适的资源?快使用搜索试试~ 我知道了~
Fair Share Scheduling for Big Systems 大系统的公平共享调度.doc
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 178 浏览量
2024-04-02
14:31:13
上传
评论
收藏 235KB DOC 举报
温馨提示
试读
12页
Fair Share Scheduling for Big Systems 大系统的公平共享调度.doc
资源推荐
资源详情
资源评论
Fair Share Modeling for Large Systems:
Aggregation, Hierarchical Decomposition and Randomization
Ethan Bolker
BMC Software, Inc,
University of Massachusetts, Boston;
eb@cs.umb.edu
Yiping Ding
BMC Software, Inc;
Yiping_Ding@bmc.com
Anatoliy Rikun
BMC Software, Inc;
Anatoliy_Rikun@bmc.com
HP, IBM and Sun each offer fair share scheduling packages on their UNIX platforms, so
that customers can manage the performance of multiple workloads by allocating shares of
system resources among the workloads. A good model can help you use such a package
effectively. Since the target systems are potentially large, a model is useful only if we
have a scalable algorithm to analyze it. In this paper we discuss three approaches to
solving the scalability problem, based on aggregation, hierarchical decomposition and
randomization. We then compare our scalable algorithms to each other and to the existing
expensive exact solution that runs in time proportional to n! for an n workload model.
1. Introduction
Fair Share scheduling is now a
mainstream technology for managing
application performance on Unix
systems. Hewlett Packard offers Process
Resource Manager (PRM) for HP-UX
[HP99], IBM offers Workload Manager
(WLM) for AIX [IBM00] and Sun offers
System Resource Manager (SRM) for
Solaris. [Sun99a], [Sun99b], [Sun00].
Fortunately, accurate models exist that
allow planners to understand how to use
that technology effectively [BD00],
[BB99]. Unfortunately, the evaluation
algorithm takes time proportional to n!
for an n workload model. On today's
processors that becomes unbearably slow
when n is about 10.
In this paper we study several ways to
speed up the computations. First we
investigate when it is possible to compute
the response times for particular
workloads of interest efficiently by
aggregating other workloads. These
aggregation answers are not encouraging,
but they are enlightening. Fortunately,
aggregation is both accurate and efficient
when studying fair share implementations
that allow the user to build a hierarchy of
workloads and then allocate shares within
that hierarchy. Finally, we present a
Monte Carlo approximation to the exact
solution for an arbitrary multi-workload
model. That approximation gives good
results quickly for models with up to 100
workloads whether or not the workloads
are hierarchically organized.
Before beginning our study let’s review
the basics of fair share semantics. We
assume the system runs a number of
transaction processing workloads whose
average arrival rates and service times are
known. That is, we assume we know the
workload utilizations. The performance
metric of interest is workload response
time. In order to meet negotiated service
level agreements (SLAs), the
administrator must be able to prioritize
the work. In fair share scheduling that is
accomplished by assigning each
workload a fractional share of the
processor, on the understanding that the
assigned share is a guarantee: if at some
moment of time just two workloads with
allocated shares of 20 and 30 respectively
have jobs on the run queue then those
workloads will divide CPU time slices in
proportion 2:3. There may be other
workloads that do not happen to have
jobs queued for service - the CPU time
slices that their share allocations might
entitle them to is not left idle.
1
2. The Standard Model
In the standard model for fair share CPU
allocation introduced in [BD00] a CPU
share of s% for workload w is interpreted
as saying that workload w runs at highest
priority s% of the time. During those
times when workload w has that highest
priority the priority ordering of the other
workloads is determined in a similar way:
each of the remaining workloads runs at
the next highest priority for a proportion
of time determined by its relative share
1
An alternative interpretation of shares treats
them as caps rather than guarantees. Then a
workload with a 20% share cannot use more than
20% of the processor even if no other work is
queued for service. This is easier to understand
and to model: each workload runs in a virtual
environment independent of the other workloads
[BD00].
among the workloads whose priority has
not yet been assigned. This interpretation
of fair share semantics assigns a
probability p(
�
) to every possible priority
ordering
�
of the workloads. There are
well known algorithms for computing the
response time R(w,i) of a workload w
running at priority i [BB83]. If we write
�
(w) for the priority of w in the
permutation
�
then the response time
R(w) for workload w can be computed as
the expected value
R(w)
=
�
�
p(
�
)R(w,
�
(w)), (1)
where R(w,
�
(w)) is the response time of
workload w when
�
is the priority
ordering.
The good news is that benchmark
experiments show that this model
correctly predicts workload response
times as a function of allocated shares
[BD00]. The bad news is that there are n!
possible priority orderings in an n
workload model, so this algorithm takes
time at least proportional to n!. Table 1
and Figure 1 show how model evaluation
time grows with the number of workloads
for a naive implementation and a
carefully optimized version of that
implementation. The times reported are
independent of workload shares and
utilizations: only the number of
workloads matters. Both curves show that
the logarithm of the time exhibits the
expected faster than linear growth. The
optimization extends the feasible range
by a few additional workloads
2
but will
not scale to larger systems.
2
At a small cost for small models.
Table 1. Model evaluation time as a
function of the number of workloads.
Time
(seconds)
Number of
Workloads n
Naive
Algorithm
Optimized
Algorithm
1
0.02
0.09
3
0.02
0.09
6
0.02
0.09
7
0.06
0.09
8
0.56
0.09
9
5.58
0.09
10
62.89
0.86
11
749.69
9.66
Moreover, even an improvement of
several orders of magnitude in hardware
performance would allow us to evaluate
only models with up to fifteen workloads.
Clearly we need new ideas and solutions.
Figure 1. Model evaluation time as a
function of the number of workloads.
0.01
0.1
1
10
100
1000
0 5 10 15
Number of Workloads
Time (sec, log scale)
Naïve Algorithm
Optimized Algorithm
2. Aggregation
Table 2 shows the workload utilizations,
shares and response times for one of the
largest models we can evaluate in
reasonable time with the optimized
algorithm. This particular model has 10
workloads with utilizations decreasing
from nearly 60% to less than one percent.
The total utilization is 90%. Each
workload runs transactions that require
one second of CPU time, so that response
times really reflect workload
performance, not job size. All the
workloads have the same share (10%). Of
course this is not a model of any real
system. We chose its parameters in a
systematic simple way in order to show
clearly how those parameters affect
response times. The lessons learned will
apply to real systems.
Table 2. Response times in a 10
workload model. Transaction service
times are 1 sec, so utilization has the
same value as arrival rate (in jobs/sec).
Wkl #
Utilization
Share
Resp. time
1
0.581
0.1
6.40
2
0.145
0.1
13.18
3
0.065
0.1
17.15
4
0.036
0.1
19.28
5
0.023
0.1
20.48
6
0.016
0.1
21.19
7
0.012
0.1
21.64
8
0.009
0.1
21.95
9
0.007
0.1
22.16
10
0.006
0.1
22.32
Before we see how we might evaluate
this model faster and thus position
ourselves to tackle still larger models we
can draw some interesting conclusions
from this data.
1. The average transaction response time,
weighted by workload utilization, is 10
seconds. The Response Time
Conservation Law says that sum will be
the same as the identical response time all
剩余11页未读,继续阅读
资源评论
百态老人
- 粉丝: 1867
- 资源: 2万+
下载权益
C知道特权
VIP文章
课程特权
开通VIP
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功