This document describes an integer linear programming (ILP) model and heuristic approach for scheduling jobs in a data center while maximizing benefits related to power costs, revenue, migration costs, and quality of service. The ILP formulation is implemented in CPLEX and a greedy randomized adaptive search procedure (GRASP) metaheuristic is designed to find near-optimal solutions more efficiently. Two variants of the GRASP heuristic are tested on generated problem instances and results are compared to the optimal ILP solutions in terms of solution quality and runtime.

1. 2012
An Integer Linear Programming
Representation for DataCenter
Power-Aware Management
-ILP implementation and
Heuristic design
Ioanna Tsalouchidou
Arinto Murdopo
Josep Subirats
Communication Networks Optimization
2012

2. Table of Contents
1. Introduction .......................................................................................................................................... 4
2. ILP problem formulation ....................................................................................................................... 5
2.1. Problem satement ........................................................................................................................ 5
2.2. Scheduling Approach .................................................................................................................... 5
2.3. Revenue, Power cost, Migration cost and Quality of Service as factors ...................................... 7
2.4. The final Model ............................................................................................................................. 7
3. Metaheuristic Design .......................................................................................................................... 10
3.1. GRASP Overview ......................................................................................................................... 10
3.2. GRASP Heuristic Implementation ............................................................................................... 11
3.3. Random Job Choosing improvement .......................................................................................... 12
4. Dataset Generation ............................................................................................................................. 13
4.1. Node capacity array generation.................................................................................................. 13
4.2. Min/Max job CPU requirement array generation....................................................................... 13
5. Experiment Result ............................................................................................................................... 14
5.1. Experiment Platform and Configuration ..................................................................................... 14
5.2. Execution Time............................................................................................................................ 14
5.3. GRASP Heuristic Alpha Value ...................................................................................................... 15
5.4. GRASP Heuristic Solution Rate Quality ....................................................................................... 18
5.5. Maximum Benefit Comparison - CPLEX and GRASP Heuristic .................................................... 19
6. Conclusions ......................................................................................................................................... 21
7. Future Work ........................................................................................................................................ 22
7.1. Implementation of the Local Search Phase of GRASP ................................................................ 22
7.2. Simulations with Multiple Problem Instances ............................................................................ 22
8. References .......................................................................................................................................... 24
2

3. Table of Figures
Figure 1: Scheduling problem ....................................................................................................................... 5
Figure 2: Job scheduling ................................................................................................................................ 6
Figure 3: Simple scheduling approach .......................................................................................................... 6
Figure 4: Final scheduling ILP model ............................................................................................................. 8
Figure 5: General GRASP algorithm ............................................................................................................ 10
Figure 6: Job's benefit evaluation ............................................................................................................... 11
Figure 7: Execution time of the CPLEX solution .......................................................................................... 14
Figure 8: Execution time for 100H200J R .................................................................................................... 15
Figure 9: NR GRASP Heuristic results .......................................................................................................... 16
Figure 10: R GRASP Heuristic results .......................................................................................................... 17
Figure 11: Normalized benefit over time for NR GRASP Heuristic.............................................................. 18
Figure 12: Normalized benefit over time for R GRASP Heuristic ................................................................ 19
Figure 13: CPLEX and R/NR GRASP Heuristic results .................................................................................. 20
Figure 14: Possible local search phase approach........................................................................................ 22
3

4. 1. Introduction
This project is based on the paper “An Integer Linear Programming Representation for DataCenter
Power-Aware Management” [1]. This paper describes the problem of the placement of jobs in a data-
centre in order to maximize its benefit, while taking into account the revenue obtained for executing the
jobs, SLA penalization costs, migration costs and energy consumption costs.
In this project, the integer linear problem described in the aforementioned paper has been
implemented using IBM ILOG CPLEX, in order to be able to obtain the optimal solution of different
problem instances. The main contribution of this project has been the implementation of a GRASP
metaheuristic (with two variants) which tries to find a good solution to the same problem in much less
time than the original ILP. The metaheuristic has been implemented using Java, and has been tested and
compared against the results provided by the CPLEX ILP implementation.
The structure of this document is as follows. Section 2 summarizes the problem statement as described
in [1]. In Section 3, an overview of the GRASP heuristic is provided, along with an explanation on the
implemented metaheuristic. Closely related to Section 3, Section 4 explains the dataset generation
procedure, which is used to run the simulations. Performance and quality results of the metaheuristic
are presented in Section 5. Finally, conclusions on the work done are exposed in Section 6, while in
Section 7 the possible improvements which could be made on it are envisioned.
4

5. 2. ILP problem formulation
2.1. Problem satement
In the proposed paper a data-centre is modelled as a set of physical machines, processors and jobs. For
each element a set of constraints have to be accomplished in order to be coherent with the model.
The solution to the problem comes when we find an optimal way to assign resources (in the paper, just
the number of required CPUs is considered) to jobs keeping in mind the electrical power consumption of
the resources, the migration costs (in case a job has to be moved to another physical machine), the
quality of service penalizations and finally the revenue obtained by running these jobs. In the end, a
positive benefit has to be obtained.
In this direction the above problem was defined as a function that needs to be maximized (the obtained
benefit) with the optimal balance of these four parameters. Moreover, there is a set of conditions and
restrictions that set the jobs on the resources while keeping the solution viable and real.
2.2. Scheduling Approach
The proposed model uses the benefits of the virtualization technology in order for the data centres to
be able to run several jobs in one or multiple physical machines, to share resources and above all to be
able to migrate jobs from one machine to another. This technology enables the dynamic allocation of
jobs along with consolidation, the scheduling policy that reduces the number of used resources by
allocating the most number of jobs in the least number of machines without trade-off in the QoS or
performance.
Figure 1: Scheduling problem
5

6. As it is shown in Figure 2, the problem that needs to be solved at each scheduling round is the decision
of which resources will be assigned to each job in order to maximize the overall benefit taking into
consideration the job revenue, the migration costs, the power costs and the tolerable QoS loss.
Figure 2: Job scheduling
For the scheduling process each job is supposed to have determined resource requirements, such as
CPU quota or memory space, in order to run properly. In Figure 3 we can see the constraints of the
problem as they were primarily constructed.
Figure 3: Simple scheduling approach
The scheduling problem is therefore described as a matrix (schedule[Hosts,Jobs]) describing whether a
particular job is allocated into a particular host (schedule[host,job]=1) or not (schedule[host,job]=0). The
“Unique” constraint in this case is restrictive; given that it imposes that all the jobs must be allocated in
order for the solution to be feasible. The “Capacity” constraint imposes that the capacity of each one of
the hosts must not be exceeded.
6

7. 2.3. Revenue, Power cost, Migration cost and Quality of Service as factors
The next step is the introduction of more constraints that will help us to model the maximization of the
economic benefit. Jobs are translated to money according to the data-centre pricing policy in the Service
Level Agreement (SLA). The Benefit equation is defined as follows: Benefit = Revenue - Costs.
In the next step towards the final model we try to focus on the problem of power cost and consumption
and the way in which we can possibly minimize it. As it is already known, the power curve for a given
host grows logarithmically, which means that in the case of two machines with many processors with
only one active processor, the consumption is much higher than one working machine with two active
processors.
In the following solution we consider that the number of CPUs in a host is a natural value so that the
scheduling will consider separately the processors of a given host. Moreover, the number of active CPUs
in a host must not surpass the maximum number of CPUs that a host has available.
Another handicap that is introduced through consolidation is the migration cost that is defined as the
cost that represents the amount of time wasted in moving a job from a host to another. During this
time, there is no revenue obtained from the execution of the job, and therefore must be subtracted
from the overall benefit.
The final step is to define the Quality of Service as an input to the scheduling problem. The system
allows some degradation in the provided QoS, as specified in the SLA. In order to improve consolidation
and reduce power consumption, QoS can be relaxed introducing at the same time a penalization. This
penalization is specified in Service Level Agreement. Therefore, the schedule can be altered while taking
into consideration these economic consequences.
In order to be able to measure the level of accomplishment of the job goals and the SLA, the authors
define the Health function which in its implementation is a linear function that varies from cpumin to
cpumax. In other words, a CPU assignment of cpumin (depends on each job) means a health of 0
(maximum QoS penalization), which equals to running the job in the minimal conditions, whereas a CPU
assignment of cpumax means a health of 1 (no QoS penalization), which equals to the optimal execution
of the job.
2.4. The final Model
As a result of all the above steps the final model is obtained as in Figure 4. This is also the final version of
the model that has been implemented in CPLEX.
7

8. Figure 4: Final scheduling ILP model
The presented ILP is based on the primary model, but incorporates the aspects described in Section 2.3.
Further details about the complete ILP model, the constraints, the variables and the parameters that are
specified in the above formulas are in depth explained in [1]
It is worth mentioning that in the paper, while the problem is formulated, a variable multiplication
appears. This converts the problem into a non-linear problem, which is harder and slower to solve. In
order to solve this problem, the author decomposes the constraint which took care of not exceeding the
maximum CPUs of each physical machine into several constraints (“MaxCPU”, “Capacity”, and
8

9. “QosAux1-4”). This also introduces the “quota” variable. Refer to *1+ for more details of this
decomposition.
It is also interesting to observe that the author introduced a relaxation in the “Unique” constraint in the
final problem model. In this case, it is not mandatory to schedule all the jobs in order for the solution to
be feasible. Therefore, in this case some jobs might not be scheduled in a scheduling round.
9

10. 3. Metaheuristic Design
3.1. GRASP Overview
The chosen metaheuristic for this project has been the GRASP (Greedy RAndomized Search Procedure)
metaheuristic. This metaheuristic consists in building as many feasible solutions as specified by a
maximum number of iterations (construction phase) and evaluate its benefit using the objective
function. In each of these solutions, a local search evaluation (local search phase) is applied in order to
find better solutions starting from a feasible solution. From all the evaluated solutions, the one with
maximum (when maximizing) or minimum (when minimizing) benefit is selected. This algorithm can be
observed in Figure 5.
Figure 5: General GRASP algorithm
This metaheuristic introduces randomization in the construction phase. This phase starts with an empty
Candidate List (CL) of possible placements for a given job (following the example of our problem). Then
using a greedy function which evaluates the individual benefit incurred by this particular placement, the
CL is filled. From this list, a Restricted Candidate List (RCL) containing the placements whose benefit
accomplishes Equation 1 is built. From the RCL, an element is selected randomly.
Equation 1
This randomness assures that different solutions will be built each time, although its “amount of
randomness” depends on Alpha. The RCL size depends on Alpha. If Alpha=0, it has a pure deterministic
behaviour as it always selects the best placement (only one element in the RCL). On the other hand, a
value of Alpha=1 has a completely random behaviour (all the combinations are present in the RCL),
given that any combination, regardless of its obtained benefit, can be selected.
10

11. 3.2. GRASP Heuristic Implementation
In this project, the general GRASP design has been followed. Although the local search phase has not
been implemented, a possible way to do it has been envisioned and is explained in the Future Work
section.
The interesting part of the GRASP design is the Greedy Function. In our case, the algorithm evaluates the
individual benefit of placing each one of the jobs in all of the hosts of the infrastructure. The individual
benefit takes into account the amount of revenue obtained by running a given job, incurred power
consumption costs of the scheduled job, QoS penalties when it’s not given the maximum amount of CPU
it requires and migration costs in case it is moved from one host in the initial schedule to another one in
the new one.
As an initial approach, all the jobs are evaluated in order (first job number 1, then job number 2 and so
on). Given that each job has a minimum and maximum CPU requirements, each placement to a
particular host is evaluated with all the possible CPU assignments. Note that each of these CPU
assignments will provide a different benefit, given that less power will be used but also the incurred SLA
penalty will be different. In case a particular placement is not possible because the destination host
doesn’t have enough free CPUs, an individual benefit of negative infinity is assigned. In this case, this
combination is not included in the Candidate List, because it would greatly modify the threshold which is
used later to build the Reduced Candidate List.
Figure 6: Job's benefit evaluation
11

12. When all the possible placements of a particular job have been evaluated, the CL is reduced into the RCL
as explained in Section 3.1. Then, one element is picked up randomly, which will be the chosen
combination. As in the general GRASP implementation, the greedy behaviour is introduced when
selecting the adopted combination from the RCL, given that it is a random selection. This combination
specifies the destination host for a particular job, as well as the assigned CPU (which is in the range
between its minimum and maximum required CPU).
When all the jobs have been evaluated and the scheduling matrix has been built, it is returned to the
general GRASP algorithm, along with the global benefit of this particular placement. If the obtained
placement achieves a better benefit than previous placements, it is stored along with its benefit.
3.3. Random Job Choosing improvement
The first approach considered in this project took each of the jobs to be placed from a list, where the
jobs were always kept in the same order. However, it is clear that the last jobs in the list will have less
possible hosts to be placed and less possible CPU assignments, as some of the hosts may be already full
with other jobs. Therefore, the first jobs in the queue have advantage over the last ones. We will refer
this approach as NR GRASP heuristic in subsequent sections.
Taking this into account, a possible way to fix this is to pick the jobs to be placed from the job list in
random order. Then, even if a job has had disadvantage in an iteration of the GRASP heuristic because it
has been evaluated at the last place, it might be evaluated in the first place in another iteration. We will
refer this second approach as the R GRASP heuristic throughout this document.
12

13. 4. Dataset Generation
4.1. Node capacity array generation
In order to be able to generate large datasets to perform large simulations, an automatic way to
generate the parameters has been implemented. One of these parameters is the capacity in terms of
number of CPUs of each host. Although the model exposed in the paper only considered up-to-4 CPU
nodes, we have extended the power model in order to cope with up-to-8 CPU nodes in order to obtain
richer results.
The capacity of each node is expressed as an array where each position represents the CPU capacity of
host “i”. It can have a capacity of 1, 2, 4 or 8 CPUs, which is assigned randomly.
4.2. Min/Max job CPU requirement array generation
As in the CPU capacity array generation, the minimum job CPU requirement is assigned a random value
from 1 to 10. Therefore, each position of the “consMin” array represents the minimum CPU
requirement of job “j”, ranging from 1 to 9. Even though 9 and 10 CPUs are not available in any node, it
was considered that having jobs which can’t be run in the infrastructure and have to be refused was a
more realistic characterization.
Once the minimum CPU consumption array has been computed, the maximum CPU consumption array
is generated. Each job’s maximum CPU requirement is calculated as its minimum CPU requirement plus
an extra 1 or 2 CPUs, chosen randomly.
13

14. 5. Experiment Result
5.1. Experiment Platform and Configuration
We used same computer to execute our CPLEX and Java heuristic code. It was a Dell Latitude E6410 with
Intel i7 M640 @2.8 GHz CPU, 8 Gigabytes of RAM, and 64-bit Windows 7 Operating System. We used
IBM ILOG CPLEX Optimization Studio 12.4 and our GRASP Java heuristic code was executed on top of
JRE 1.6.0_24-b07 from Oracle.
We simulated the following problem sizes: 5H10J (5-hosts-10-jobs), 15H30J, 20H40J, 30H60J, 40H80J
and 100H200J. For each problem size, we experimented with multiple Alpha ( ) values ranging from 0 to
1, with steps of 0.1 (0, 0.1, 0.2, 0.3 …. 1).
For the heuristic executions, we used multiple iteration configurations as follows: 10, 100, 1000, 10000
and 100000 iterations. We measured different performance aspects of both R and NR heuristic types.
The obtained results are discussed in the following subsections.
5.2. Execution Time
First of all, we measured the execution time in CPLEX for different problem sizes and compared them. As
expected, CPLEX takes a very long time to complete when the problem size is big. In our case, CPLEX was
able to complete a 20H40J instance in 228 seconds.When the problem size was increased to 30H60J,
CPLEX didn’t finish its execution, even though we let it run for 66 hours. We used the available CPLEX
results to measure the quality of the GRASP heuristic solution. Figure 7 shows the execution time of our
CPLEX solution.
Figure 7: Execution time of the CPLEX solution
14

15. Next, we continued to measure the execution time of the GRASP heuristic. GRASP is able to run for
larger problem sizes. Its execution time strongly depends on the number of iterations and the
configured problem size. We measured the execution time for all of the aforementioned problem sizes
and iteration configurations. In Figure 8, the execution time for the highest problem size of 100H200J is
shown.
Figure 8: Execution time for 100H200J R
The x-axis is displayed in logarithmic scale. In normal scale, the heuristic execution time has a linear
correlation with the number of iterations. It is interesting to observe that the GRASP heuristic performs
much better than CPLEX in terms of execution time. For example, the execution time of the GRASP
heuristic with 100H200J and 100000 iterations is 80 seconds faster compared to CPLEX with 20H40J.
However, the superiority of the GRASP heuristic can not be evaluated only in terms of execution time, it
also has to be taken into account the quality of the obtained solution. Therefore we also need to
measure the performance of our GRASP heuristic in terms of solution quality. This aspect will be
discussed in section 5.5.
5.3. GRASP Heuristic Alpha Value
In this section, we obtain the optimal Alpha value for the GRASP heuristic. For every problem size and
every iteration, we obtained the diagram depicting the relation between Alpha, Benefit, Number of
Iterations, and type of GRASP heuristic. NR refers to not-random job selection GRASP (NR GRASP
heuristic), and R refers to random job selection GRASP (R GRASP heuristic).
15

16. Figure 9: NR GRASP Heuristic results
Figure 9 shows the results for the NR GRASP heuristic with four types of problem sizes. Based on these
results, it is shown that maximum benefit will be achieved with low Alpha values (0.1, 0.2, 0.3). We also
can see that the more the number of the iterations, the higher the obtained benefit is. As it was
explained in Section 3.1, a value of Alpha=0 has a completely deterministic behaviour, given that only
the combination with the best benefit is chosen when building the Reduced Candidate List, and
therefore is always the one selected in the end. Note that no randomness is introduced in the job
choosing either, as they are selected always in order. This behaviour can be clearly observed in the
previous figure: regardless of the number of iterations, the obtained benefit is exactly the same.
16

17. Figure 10: R GRASP Heuristic results
Figure 10 shows the results for the R GRASP heuristic with four types of problem sizes, the same ones
that we used to measure NR GRASP heuristic Alpha value. They show the same trend as NR GRASP
heuristic whereby low Alpha values (0, 0.1, 0.2, 0.3) result in higher benefit compared to other Alpha
values. The number of iterations also determine the quality of the benefit and the higher the iteration,
the higher the obtained benefit value. It is also interesting to note that for high problem sizes (30H60J,
40H80J, 100H200J), the highest value is obtained when Alpha is 0. This result means that early
randomization in picking up jobs to be evaluated is more prevalent in producing better results than
randomization in the selection of candidates from the Restricted Candidate List (whose size depends on
the value of Alpha).
Both NR and R GRASP heuristic therefore obtain better benefits when the Alpha Value is small, typically
between 0 to 0.3, both included.
17

18. 5.4. GRASP Heuristic Solution Rate Quality
In this section, we analyze how fast our GRASP heuristic algorithm reaches some significant percentages
of the best solution it provides. We define “significant percentages” as more than 90% of the best
solution that can be found using GRASP (sometimes, it reaches the optimal solution).
To perform this analysis, we used the largest problem size configuration (100H200J). For NR GRASP
heuristic, we used an Alpha value of 0.1 and 100000 iterations, while for R GRASP heuristic we used an
Alpha value of 0 and 100000 iterations.
Figure 11: Normalized benefit over time for NR GRASP Heuristic
Figure 11 shows the normalized benefit over time for the NR GRASP heuristic. The y-axis is the
normalized benefit, which is the percentage of benefit compared to maximum benefit that can be
obtained in this configuration. Note that since we were not able to use CPLEX to obtain the best benefit
for 100H200J, we used the maximum benefit obtained by NR GRASP heuristic to calculate the
normalized benefit. The x-axis denotes the time in mili-seconds. From the figure, we observe that within
12.377 seconds, our NR GRASP heuristic is able to reach around 99.95% of its maximum benefit.
18

19. Figure 12: Normalized benefit over time for R GRASP Heuristic
Figure 12 shows the results of the R GRASP heuristic. As in the NR GRASP heuristic results, we used the
maximum benefit obtained by the R GRASP heuristic to calculate the normalized benefit. The R GRASP
heuristic is able to reach 93% of maximum benefit within 0.617 seconds and 97.3% of maximum benefit
within 8.813 seconds.
Both NR and R GRASP heuristics have a very good performance in terms of speed to reach more than
90% of its maximum benefit.
5.5. Maximum Benefit Comparison - CPLEX and GRASP Heuristic
CPLEX is guaranteed to obtain the optimal result for our problem statements. However, it has a
drawback in its execution time. CPLEX execution time is very long and it is not affordable for big problem
sizes. On the other hand, heuristics in general have smaller execution times but their results should be
compared to those of CPLEX in order to evaluate its quality. Figure 13 shows the comparison between
CPLEX and GRASP heuristic results for multiple problem sizes. It also presents two different instances of
R GRASP heuristics, one with 10000 iterations and the other with 100000 iterations.
19

20. Figure 13: CPLEX and R/NR GRASP Heuristic results
For the smallest problem size (5H10J), all of them have the same maximum benefit. However, at 10H20J,
we already observe that NR GRASP with 100000 iterations is not able to reach the optimal solution
obtained by CPLEX. But R GRASP with 10000 iterations and 100000 iterations managed to produce
CPLEX’s optimal benefit values. The same trend is observed for 15H30J problem size, but things started
to get interesting in 20H40J where R GRASP with 10000 iterations was not able to produce maximum
value produced by CPLEX. Here we can observe that the number of iterations also affect the maximum
obtained benefit. We also can claim that our R GRASP heuristic produces good results, and its obtained
maximum benefit equals to the CPLEX’s optimal benefit for all the simulations where CPLEX data was
available.
For bigger problem sizes (30H60J, 40H80J, 100H200J) we were not able to obtain CPLEX results due to its
extremely long execution times. We observe that R GRASP heuristic with 100000 iterations produces the
maximum benefit compared to the other configurations of the GRASP heuristic. Execution time of
100000-iteration-R GRASP heuristic is around 5 minutes and it is still reasonable.We could not confirm
whether the resulting value is the optimal benefit value but based on good comparison results with
CPLEX for smaller problem sizes, we are assured that the resulting value is pretty good also. In this case,
we can improve the quality of the solution by increasing the number of iterations if we have enough
time and resources to perform that.
20

21. 6. Conclusions
In this project, we have implemented an ILP problem for data-center job scheduling and management.
We used IBM ILOG CPLEX to solve our ILP model. We also implemented two types of GRASP heuristic to
solve the scheduling problem, they are Non Random Job Selection GRASP (NR GRASP heuristic) and
Random Job Selection GRASP (R GRASP heuristic). During the GRASP heuristic methods implementation,
we found that complex ILP restrictions or constraints can be translated into relatively easy heuristic Java
code.
R GRASP heuristic performs better than NR GRASP heuristic. For four small problem sizes that CPLEX is
able to produce maximum benefit, we found that R GRASP heuristic with 100000 iteration also managed
to obtain CPLEX’s optimal benefit. However, NR GRASP heuristic is only able to produce around 83.5% of
the maximum benefit for 15H30J and 88.11% of the maximum benefit for 10H20J case.
In both GRASP implementation, lower Alpha values produce better results. And interestingly, for R
GRASP heuristic, the best result is obtained when Alpha is 0. We also observe that more iterations will
achieve better results, but the execution time will increase.
Regarding the scalability of the solution, based on our experiment, CPLEX does not really scale well as its
execution time grows exponentially. When we increased the problem sizes, CPLEX was not able to finish
its optimization process although we let it run for 66 hours. On the other hand, GRASP heuristic scales
well. We were able to use it to solve the problem for bigger problem sizes with acceptable times and
solution qualities. With the biggest problem size that CPLEX can run, R GRASP heuristic is still able to find
the same benefit as CPLEX, which is the optimal one.
21

22. 7. Future Work
7.1. Implementation of the Local Search Phase of GRASP
We could further improve our implementation of the GRASP heuristic by including the Local-Search
phase in our heuristic. One way to implement the Local-Search is to perform benefit comparisons
between the solution obtained by the Greedy Function and a modification of this same solution in which
some jobs are not migrated between nodes. Refer to Figure 14. After the Greedy Function obtains a
New Schedule, we create local search candidate (a neighbour of the obtained solution) where Job 1 and
Job 5 are not migrated with respect to the Old Schedule. We can repeat this process by producing
several local search candidates (neighbours of the original solution) and compare their results with the
original New Schedule obtained by the Greedy Function.
Figure 14: Possible local search phase approach
7.2. Simulations with Multiple Problem Instances
When evaluating the performance and quality of the solutions obtained by the GRASP heuristic, only
one problem instance for each problem size was executed. This means that only one set of parameters
22

23. (CPUs per host, minimum and maximum CPU requirements per job) was generated to perform the
simulations for each problem size. In order to have a more realistic view of the GRASP performance,
multiple sets of parameters for a given problem size could be generated, and evaluate the performance
of the heuristic for different inputs of the same size.
23

24. 8. References
[1] Josep Ll. Berral, Ricard Gavaldà, Jordi Torres. “An Integer Linear Programming Representation for
DataCenter Power-Aware Management” Research Report number: UPC-LSI-10-21-R, November 2010.
24