Ener Energy gy and and Pe Performance Can Can a Wi Wimpy mpy - - PowerPoint PPT Presentation

Ener Energy gy and and Pe Performance – Can Can a Wi Wimpy mpy‐Node Node Cl Clus uster Challeng Challenge a Br Brawn awny Ser Server? er?

Daniel Schall Theo Härder University of Kaiserslautern, Germany

Motivation

BTW 2015 2

‘‘Analyzing the Energy Efficiency

• f a Database Server“,

Tsirogiannis, Harizopoulos, and Shah SIGMOD 2010 ‘‘Distributed Computing at Multi‐ dimensional Scale“, Alfred Z. Spector Keynote on MIDDLEWARE 2008

Motivation

•  state‐of‐the‐art servers waste lots of energy

BTW 2015 3

“Average CPU utilization of more than 5,000 servers”

• A. Barroso and U. Hölzle:

The Case for Energy‐Proportional Computing

Energy Efficiency

• EE = (relative load / rel. energy consumption)
• best efficiency at 100 % load, i.e. efficiency = 1,0
• efficiency quickly drops:
• with the same energy budget, the server performs only 14

% of work at 10 % load

• and takes 10 times as long

4

load 90 % 70 % 50 % 30 % 10 % efficiency 90 % 73 % 55 % 35 % 14 %

BTW 2015

Energy Efficiency

• energy consumption proportional to system utilization

BTW 2015 5

% 20 40 60 80 100 System utilization

Power

Consumption % 20 40 60 80 100 power@utilization

energy‐ proportional behavior

load 90 % 70 % 50 % 30 % 10 % efficiency 90 % 73 % 55 % 35 % 14 % load 90 % 70 % 50 % 30 % 10 % efficiency 100 % 100 % 100 % 100 % 100 %

_______________ Ener Energy gy Proportionality

• portionality

• single server
• static configuration

The WattDB Approach

• cluster of nodes
• dynamically adjust to current workload
• turn nodes on/off according to demand
• migrate data to balance workload

6

% 20 40 60 80 100 System utilization

Power Consumption

% 20 40 60 80 100 1 beefy server n wimpy servers

BTW 2015

database workloads

• transactional consistency
• shared data
• large data volume
• read / write workloads

elasticity

• automatic scale‐out and ‐in
• fit storage and processing to

workload

• minimize impact on

performance

• save energy

7

The WattDB Approach

vs. migrate data, while keeping it available distribute queries, on a variable number of nodes balance performance and energy consumption

Implementation:

• combine elastic storage and processing
• migrate ownership with data
• enable adaption to both:

IO and CPU demands

• shared disk „with a twist“
• physiological repartitioning

for fast adaption

8

The WattDB Approach

elastic processing elastic storage elastic DBMS

BTW 2015

• physiological partitioning
• self‐contained mini‐partitions (32MB)
• with primary‐key index
• top meta‐index (key ranges)
• modified MVCC for updates

9

32 MB IX Key ranges Key ranges

The WattDB Approach

BTW 2015

The WattDB Approach

• extrapolate time series from monitoring data
• generate forecast over next 60 minutes

 from reactive to proactive

10 BTW 2015

The WattDB Approach

so far:

• promising results compared to static clusters
• better energy efficiency
• without sacrificing too much performance

Question of the day:

• compare prototype with state‐of‐the‐art server
• performance and energy efficiency
• realistic workloads

11 BTW 2015

Cluster

• 10x Intel Atom D510 CPU
• @ 1.66 GHz
• 20/40 cores
• 20 MB of L2 Cache
• 20 GB DRAM

BigServer

• 2x Intel Xeon X5670
• @ 2.93 GHz
• 12/24 cores
• 24 MB of L2 Cache
• 24 GB RAM

BTW 2015 12

Cluster vs. BigServer

Performance Figures

• similar performance on paper
• in theory

13 BTW 2015

Power Consumption

BigServer exhibits

• higher energy consumption
• no energy proportionality

14 BTW 2015

Experimental Setup

• OLAP and OLTP experiments on both systems

OLAP

• TPC‐H dataset with SF 300
• LINEITEM and ORDERS are partitioned
• TPC‐H like queries

OLTP

• TPC‐C dataset with SF 1.000
• TPC‐C like queries
• number of parallel DB clients determines workload
• think times to avoid performance‐only benchmark for dynamic

workload

15 BTW 2015

Performance‐centric Experiments

• OLAP performance
• server generally faster
• server better suited for

peak workloads

• OLTP performance
• server clearly wins
• especially under heavy

utiliziation

16 BTW 2015

number of DB clients

Energy‐centric Experiments

• OLTP, target response time: 200 msec
• performance and power consumption of server lower
• cluster exhibits high friction losses

17

Runtime

BTW 2015

Energy consumption

• OLAP, target response time: 20 sec
• server‘s idle time penalized
• cluster is more energy efficient

Energy‐centric Experiments

18

Runtime

BTW 2015

Energy consumption

Dynamic Workload

• workload trace
• derived from DB performance monitoring traces
• workload changes every 5 minutes
• 1:15 hours total runtime
• simulate real‐world database utilization

19 BTW 2015

Dynamic Workload

• OLTP

20 BTW 2015

Runtime Power consumption Energy consumption

• OLTP
• cluster is more energy efficient

 ½ the energy cons.

• server is a lot faster

 1.4 times throughput

• forecasting trades performance for energy efficiency

Dynamic Workload

21 BTW 2015

Dynamic Workload

• OLAP

22 BTW 2015

Runtime Power consumption Energy consumption

Dynamic Workload

• OLAP

forecasting cluster

• exhibits challenging performance  78% throughput
• less energy consumption

 40 % energy

23 BTW 2015

Dynamic Workload

• Energy Delay Product
• forecasting pays off (better perf., slightly higher ec)
• predictability / forecasting crucial for OLTP
• energy efficiency worth the performance drop?

24 BTW 2015

Energy Consumption x Runtime = EDP Joule x seconds = Js ( = Ws²)

Conclusion

• no use for performance‐centric workloads
• energy savings at low to midrange workloads
• especially for OLAP
• OTLP harder to make energy proportional
• predictable workloads needed
• forecasting crucial
• proactively prepare for upcoming workloads
• OLAP better suited than OLTP
• streaming
• less close to data

http://wattdb.de Thank You!

<

25