2017 IEEE 41st Annual Computer Software and Applications Conference

Energy Consumption Measurements in Docker

Senay Semu Tadesse Carla-Fabiana Chiasserini Francesco Malandrino
Politecnico di Torino, Italy Politecnico di Torino, Italy Politecnico di Torino, Italy

Abstract—Containerization, often referred to as lightweight

virtualization, is one of the key building blocks of next-generation
networks. In this paper we consider Docker, the de facto stan-
dard containerization solution, and seek to measure the power
consumption it is associated with. We perform our tests with
real, off-the-shelf hardware and using several heterogeneous types
of load. We find that, while CPU usage represents the main
contribution to the overall consumption, other aspects need to
be accounted for, both within and out of Docker.

I. I NTRODUCTION AND RELATED WORK

Network function virtualization (NFV) is arguably, along
with software-defined networking (SDN), the most significant
innovation that is shaping next-generation wired and wireless
networks. Its main promise is to make any network node able
to perform any function, thus increasing network flexibility
and efficiency.
Virtual machines (VMs) represent the traditional way of
implementing virtualization. They simulate a complete system,
including hardware and operating system, which implies that a
different OS and processor from the host ones can be exposed
to virtualized applications. Furthermore, complete isolation
between guest and host machines is achieved. On the negative
side, virtual machines come with severe overhead in terms of
CPU usage, memory consumption, and network delay.
Containerization has recently emerged as a lightweight
alternative to virtual machines. Applications run within con-
tainers, which share the same operating system, kernel, and
process space as the host machine, while keeping filesystems
isolated. Filesystems contain whatever applications need to
run: code, runtime, and system libraries. Containers offer a
lower level of isolation than virtual machines, and are in
general a less mature technology. On the positive side, they
imply only a fraction of the overhead associated with virtual
machines: they can start (almost) instantly, and use a negligible
amount of additional memory.
Docker is the current de facto standard for containerization,
and the first commercially successful solution. Its architecture
is summarized in Fig. 1: a Docker daemon, equivalent to
a virtual machine hypervisor, runs several containers, each
running a different application on a separate filesystem. Notice
that the operating system kernel is shared among containers
(i.e., all applications run on the same OS and OS version as
the guest), and that data has to traverse the kernel’s network
stack when traveling from a container to another.
In this paper, we study the power consumption associated
with Docker containers when they run several basic test
applications, from CPU-intensive computations to high-rate
network transfers. We characterize the power consumption
Fig. 1. Docker architecture: the Docker daemon runs several containers, each
running a different application. The kernel is shared among containers, and
packets transmitted between containers traverse its network stack.
as the load varies, thus building models that can be used to
estimate the power footprint of more complex applications.
Measuring the power consumption of virtualization envi-
ronments and applications running on them is the subject
of several existing works. Kansal et al. [1] have developed
Joulemeter, a tool to measure the energy consumption of
a virtual machine and break it down as the sum of the
individual power consumptions of CPU, memory and disk.
Krishnan et al. [2] have modeled the power consumption
of virtual machines as a linear function of the number of
CPU instructions and the number of Last Level Cache (LLC)
memory misses. Bertran [3] proposed a system based on
CPU and memory power models, relying on Performance
Monitoring Counters (PMCs), to perform energy accounting in
virtualized systems. Morabito [4] has presented an empirical
investigation of different virtualization technologies (including
containers) from the viewpoint of power consumption.
The remainder of this paper is organized as follows. In
Sec. II, we describe our test machine and the test applications
we study. We then discuss our main results in Sec. III, and
conclude the paper in Sec. IV.
II. T ESTBED AND APPLICATIONS
For our tests, we use a common (and somehow aging)
desktop, namely, HP Compac 8000 Elite CMT business PC
with a dual-core 2.66 GHz processor and 2 GBytes of RAM.
It runs the Ubuntu 14.04.5 LTS operating system, with ker-
nel 4.4.0-31-generic. Both the processor and the operating
system support hyper-threading, which raises the number of
tasks that can be run at the same time to four.
RCE PM600 power meter is used to read real-time power
statistics. All tests are run for 2 minutes, and power samples
are read from the power meter.

0730-3157/17 $31.00 © 2017 IEEE 272

DOI 10.1109/COMPSAC.2017.117
 55 30 160
Linear Fitting Data
50 Data Polynomial Fitting

Power Consumption by Docker (W)

Power Consumption by Docker (W)

25

CPU Utilization of Docker (%)

45
40 120
20
35
30
15 80
25
20
10
15 40
10 5
5
0 0 0
0 100 200 300 400 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
CPU Utilization of Docker (%) Data Rate (Gbits/s) Data Rate (Gbits/s)

Fig. 2. CPU Test: power consumption vs CPU utilization (left); Network Test: power consumption vs data rate (center), CPU utilization vs data rate (right).

CPU test. The first application we test is a CPU-intensive after 0.8 Gbit/s. This is due to the fact that, between 0.6
task, continuously performing matrix products with the numpy and 0.8 Gbit/s, we hit the maximum rate at which data transfers
library. Because numpy is single threaded, this application can occur: we can set a rate of, say, 1 Gbit/s in iperf, but
will employ at most one CPU core, even if more are available. only a fraction of that data gets to the destination.
Network test. We also consider a typical network transfer Now let us compare Fig. 2(right) with the power consump-
scenario: a client container uses iperf to send an uninter- tion displayed in Fig. 2(center): while the CPU usage accounts
rupted, constant-rate flow of TCP data to a server container; for much of the power consumption, there are clearly other
neither container performs any other operation. The purpose contributions that make the consumption grow even when the
of this test is to assess whether the data rate impacts the power CPU usage becomes constant. In summary, Fig. 2(center) and
consumption, and how. Fig. 2(right) alert us that Docker CPU usage is not the only
meaningful contribution to the total power consumption. As
III. M AIN RESULTS an example, the growth in the rightmost part of Fig. 2(center)
Fig. 2(left) summarizes the results of our CPU test. Each can be due to the packets entering the Linux network stack
data point correspond to a different number of containers and then being discarded therein.
running the test: when there are up to three containers running,
each consumes almost exactly 100% of the available CPU, i.e., IV. C ONCLUSION AND ONGOING WORK
one core out of four. The rightmost point, corresponding to the We tested the power consumption of a real-world Docker
test with four containers, shows a CPU load of around 370%. testbed, under several different types of load. We found that
The remaining 30% is used by overheads, including that of Docker CPU usage always represents a significant contribution
the Docker daemon and of the operating system processes. to the overall power consumption; however, depending on the
The linear fitting is very good, and the linear regression law actual application being run, we might need to account for
is as follows: additional components, e.g., increased strain on the operating
system resources. We are currently working towards character-
P = 0.1065c + 12.4411, izing and quantifying such additional components, especially
with reference to network transfer scenarios.
where P is the power (in watt) and c is the percentage of
used CPU (e.g., 200 for two cores). In summary, Fig. 2(left) R EFERENCES
confirms the intuition that CPU usage is the main reason [1] A. Kansal, F. Zhao, J. Liu, N. Kothari, and A. A. Bhattacharya, “Virtual
behind power consumption. machine power metering and provisioning,” in ACM symposium on Cloud
computing, 2010.
In Fig. 2(center) we present the results of the network test; [2] B. Krishnan, H. Amur, A. Gavrilovska, and K. Schwan, “VM power
specifically, the plot displays the power consumption as the metering: feasibility and challenges,” ACM SIGMETRICS Performance
data transfer rate varies. We can immediately see that the Evaluation Review, 2011.
[3] R. Bertran, Y. Becerra, D. Carrera, V. Beltran, M. Gonzalez, X. Martorell,
dependence is more complicate than in Fig. 2(left). The best J. Torres, and E. Ayguade, “Accurate energy accounting for shared
model we found is a second order polynomial fitting: virtualized environments using pmc-based power modeling techniques,”
in IEEE/ACM GRID, 2010.
[4] R. Morabito, “Power consumption of virtualization technologies: an
P = −17.7368r2 + 37.2859r + 3.8210, empirical investigation,” in IEEE/ACM UCC, 2015.
where P is the power (in watt) consumed by Docker as ACKNOWLEDGMENT
measured by power meter and r is the data rate in Gbits/s.
This work has received funding from the 5G-Crosshaul
We try to make sense of this behavior by looking, in
project (H2020-671598).
Fig. 2(right), at how the CPU load changes with the data
rate. We can clearly see an almost-linear growth until a
rate of 0.6 Gbit/s, and then a basically constant CPU usage

273