CSE 691: Energy-Efficient Computing Lecture 6 SHARING: distributed vs. local Anshul Gandhi 1307, CS...
-
Upload
valerie-jennings -
Category
Documents
-
view
220 -
download
1
Transcript of CSE 691: Energy-Efficient Computing Lecture 6 SHARING: distributed vs. local Anshul Gandhi 1307, CS...
CSE 691: Energy-Efficient ComputingLecture 6
SHARING: distributed vs. localAnshul Gandhi
1307, CS [email protected]
energy_routing paper
# servers
workload
softscale paper
6
Goals of a data center
• Low response times • Goal: T95 ≤ 500 ms
Performance• 70% is wasted• Goal: Minimize waste
Power
Load
Time
BUSY: 200 W IDLE: 140 W OFF: 0 W
Intel Xeon server
7
Scalable data centers
Performance Power
BUSY: 200 W IDLE: 140 W OFF: 0 W
Intel Xeon server
Reactive: [Leite’10;Horvath’08;Wang’08]Predictive: [Krioukov’10;Chen’08;Bobroff’07]
Setup cost300 s
200 W(+more)
Only if load changes slowly
Load
Time
8
Problem: Load spikesLo
ad
Time
x
2x
9
Prior work
Dealing with load spikes• Spare servers [Shen’11;Chandra’03]
Over provisioning can be expensive
• Forecasting [Krioukov’10;Padala’09;Lasettre03]
Spikes are often unpredictable
• Compromise on performance [Urgaonkar’08;Adya’04;Cherkasova’02]
Admission control, request prioritization
x
Load
Time
2x
10
Our approach: SOFTScale
• No spare servers• No forecasting • Does not compromise on
performance (in most cases)
Can be used in conjunction with prior approaches
x
Load
Time
2x
Closer look at data centers
Always on
Use caching tier to “pick up the slack”
11
Scalable
High-level idea
OFF
OFF
OFFSETUP
SETUP
SETUP
Load
Time
x
2x
Dual purpose
Leverage spare capacity
12
ON
ON
ON
Experimental setup
PHP(CPU-bound)
Memcached(memory-bound)
Response time: Time for entry to exitAverage response time: 200ms (with 20X variability)Goal: T95 ≤ 500ms
Apache
13
Experimental setup
14
8-core CPU4 GB memory 4-core CPU
48 GB memory
PHP(CPU-bound)
Memcached(memory-bound)
Apache
Results: Instantaneous load jumps
15
Load
Time
50%
61%
10% 29%
T 95 (m
s)av
erag
ed o
ver 5
min
s
baseline = provisioned for initial load
Conclusion
16
• Problem: How to deal with load spikes?
• Prior work: Over provision, predict, compromise on performance
• Our (orthogonal) approach: SOFTScale
Leverages spare capacity in “always on” data tiers
Look at the whole system Can handle a range of load spikes