In the last few years energy efficiency of large scale infrastructures gained a lot of attention, as power consumption became one of the most impacting factors of the operative costs of a data-center and of its Total Cost of Ownership. Power consumption can be observed at different layers of the data-center: from the overall power grid, moving to each rack and arriving to each machine and system. Given the rise of application containers in the cloud computing scenario, it becomes more and more important to measure power consumption also at the application level, where power-aware schedulers and orchestrators can optimize the execution of the workloads not only from a performance perspective, but also considering performance/power trade-offs. DEEP-mon is a novel monitoring tool able to measure power consumption and attribute it for each thread and application container running in the system, without any previous knowledge regarding the characteristics of the application and without any kind of workload instrumentation. DEEP-mon is able to aggregate data for threads, application containers and hosts with a negligible impact on the monitored system and on the running workloads. Information obtained with DEEP-mon open the way for a wide set of applications exploiting the capabilities offered by the monitoring tool, from power (and hence cost) metering of new software components deployed in the data center, to fine grained power capping and power-aware scheduling and co-location.

1. DEEP-mon
Berkeley - 05/23/2018
Dynamic and Energy Efcient Power monitoring
for container-based infrastructures
Tommaso Sardelli, Rolando Brondolin, Marco D. Santambrogio

2. Data Center - Power Consumption
Environment
20%
Of Costs
wasted on
power
consumption[1]
Power
Cap
Costs
Y. Cui, C. Ingalz, T. Gao, and A. Heydari, “Total cost of ownership model for data center technology
evaluation,” in Thermal and Thermomechanical Phenomena in Electronic Systems (ITherm), 2017 16th
IEEE Intersociety Conference on. IEEE, 2017, pp. 936–942.
2

3. Need For Power Awareness
Power
Aware
balancing
of IT
workloadsPower
Efciency
Monitoring
Data
Driven
3

4. Kubernetes Orchestration
4
Manage
Container
Execution
environments
https://kubernetes.io

5. Need For Power Awareness
5
Observe
Decide
Act

6. Application Level Power Attribution
6
CPU: 78 W
DRAM: 41W
CPU: 121 W
DRAM: 34W
Server Level
power attribution

7. Application Level Power Attribution
Server Level
power attribution
Application Level
power attribution
CPU: 78 W
DRAM: 41W
CPU: 121 W
DRAM: 34W
CPU: 21 W
DRAM: 5W
CPU: 16 W
DRAM: 4W
CPU: 114 W
DRAM: 29 W
7

8. DEEP-mon
8
Runtime Monitoring
Container Power Consumption
Low Overhead
CPU: 21 W
DRAM: 5W
CPU: 16 W
DRAM: 4W

9. DEEP-mon Architecture
9
User
Space
Backend
Kernel
Space
Clock
Cycles
Instr.
Retired
Exec.
Time

10. Kernel - Runtime Monitoring
10

11. Kernel - Runtime Monitoring
11

12. Kernel - Runtime Monitoring
12

13. Problem
200,000
context_switch/s
13

14. Problem - Overhead
Kernel
Space
User
Space
prev_pid
prev_comm
next_pid
next_comm
sched_switch_args
14

15. Solution – In Kernel Aggregation
Use eBPF to aggregate PMC values in
kernel space
Share aggregated values with user
space using per-process hash tables
Deal with one event per second instead
of 200k
15
Container
C
Container
B
Container
A

16. User Space Power Attribution
16
Container
C
Container
B
Container
A
PMC
PMC
PMC

17. User Space – Power Attribution
17
BPMC
APMC CPMCBPMC

18. User Space – Power Attribution
18
BPMC
APMC CPMCBPMC

19. User Space – Power Attribution
19
BPMC
APMC CPMCBPMC

20. Kubernetes – Data Enrichment
20
CPU: 21 W
DRAM: 5W
CPU: 16 W
DRAM: 4W
Application Name
Hostname
IP Address
Namespace

21. DEEP-mon Backend
21

22. Benchmarks - Setup
22
Objective : Measure performance and power
consumption overhead introduced by the agent
2x Intel Xeon E5-2680 40 threads - 380GB RAM
Ubuntu 16.04 Linux 4.13 with eBPF support
HPC
Benchmark
Cloud
Benchmark
Phoronix
Test
Suite
NAS
Parallel
Benchmark

23. Execution Time Overhead
23
Phoronix Test SuiteNas Parallel Benchmark
3.8%
4.2%0.4%
0.4%
-2.05%
3.1%

24. NGINX - Latency
24
Latency # Requests Transfer Rate 99th
Latency
38.35 ms 8720 req/s 140.17 MB/s 1100.0 ms
41.62 ms 8793 req/s 141.08 MB/s 1130.0 ms
W/ Agent
W/O Agent
20 NGINX threads
20 wrk threads to generate load
30 consecutive runs
Setup

25. Power Consumption Overhead
25
Phoronix Test SuiteNas Parallel Benchmark
0.22%
0.93%
1.56%
1.80%
0.45%
2.98%

26. Conclusions
26
Fine grained container power monitoring
Low overhead thanks to in-kernel aggregation
Validation of the approach with a cloud-like
and an HPC-like benchmark

27. Future Work
27
Impact on latency-sensitive applications
Adjust dynamic window for long running jobs

28. https://necst.it/
https://www.slideshare.net/necstlab
Tommaso Sardelli {tommaso.sardelli@mail.polimi.it}
Rolando Brondolin {rolando.brondolin@polimi.it}
Marco D. Santambrogio {marco.santambrogio@polimi.it}
Thank You