Reducing Noisy-Neighbor Impact with a Fuzzy Affinity- Aware Scheduler

Size: px

Start display at page:

Download "Reducing Noisy-Neighbor Impact with a Fuzzy Affinity- Aware Scheduler"

Candice McCoy
5 years ago
Views:

Reducing Noisy-Neighbor Impact with a Fuzzy Affinity- Aware Scheduler L U I S T O M Á S A N D J O H A N T O R D S S O N D E PA R T M E N T O F C O M P U T I N G S C I E N C E U M E Å U N I V E R S I

1 Reducing Noisy-Neighbor Impact with a Fuzzy Affinity- Aware Scheduler L U I S T O M Á S A N D J O H A N T O R D S S O N D E PA R T M E N T O F C O M P U T I N G S C I E N C E U M E Å U N I V E R S I T Y, S W E D E N C A R L O S VA Z Q U E Z A N D G I N E S M O R E N O D E PA R T M E N T O F C O M P U T I N G S Y S T E M S U N I V E R S I T Y O F C A S T I L L A - L A M A N C H A, S PA I N S U M M A R I Z E D B Y: D A R W I N M A C H F O R : C S A U TO N O M I C C O M P U T I N G FA L L G E O R G E M A S O N U N I V E R S I T Y

2 Overview Background Problem Statement Proposed Solution Controller Design Feedback Loop Classifier & Estimator Experimental Design Observations 2

3 Background Virtual machines (VMs) share resources on their hosts Cloud providers faced with over-booking vs under-booking Over-book: Allow more virtual resources allocated than available physical Under-book: Opposite Over-booking is normal because not all VMs will be 100% utilized At least not at all times Allows for cost savings Increases utilization ratio 3

4 Problem VMs in the same host can fight for physical resources when 2 or more needs them Performance degradation from resource contention Happens regardless of over-booking or under-booking Some resources will always be shared in a VM environment Called the noisy neighbor 4

5 Related Works Scope/Focus: In-server resource scheduling In particular, CPU (physical core) sharing Intra-server not inter-server Control overbooking ratio User-provided overbooking tolerance [10] Static, dependent on physical infrastructure, and handle uncertainty well Change ratio over time [12] [13] Missing mechanism to handle resource shortage after application admitted Detect and resolve [18] [19] [20] Not proactive 5

6 Proposed Solution Steps: Determine VM needs Get status of each core Match the VMs to the cores Use CPU pinning (via Kernel Virtual Machine, KVM) Do this before admitting new application and when periodically monitoring host 6

7 Controller Design: Feedback Loop WHERE: Which server to book (previous work) [11] HOW: Which CPUs to pin KPIs: Response time, throughput Feedback Affinity Loop Application KPIs Fuzzy Logic Engine Scheduler repeat Fuzzy Logic Controller Increase affinity Decrease affinity 7

8 Fuzzy Logic Connectives (Operators) 8

9 Fuzzy Logic Connectives (Operators, con t) Other connectives used: Aver ( x) ҧ aver(x, y) Not (~) not x = 1 x Connective Conjunction Disjunction Implication Classic Operator ^ (AND) V (OR) (If/Then) Approx ( ) approx x = Very very x = x 2 x Definition depends on pessimistic (L), optimistic (G), or realistic (P). See Figure 2. Over (possibility of overload) x@ over y = min{max 0, x + y 1, 1} 9

10 Controller Design: Classifier & Estimator CPU resource utilization X_Intensive(core) X_Bursty(core) Estimate affinity across capacity dimensions Intensity (Eq. 3) Burstiness (Eq. 4) 10

11 Controller Design: Classifier & Estimator (con t) Combine affinities Intensive using Pessimistic (L) Ensure stability Burstiness using Optimistic (G) Bursts are not usually severe, given short duration and doesn t collide Use very(x) for memory (more critical) Merge to final affinity using Realistic (P) 11

12 Experimental Design 2 computers Application host (32 cores, AMD Opteron TM 2.1 GHz, 56 GB RAM) Workload generator (4 cores, Intel Core TM i5 3.4 GHz, 16 GB RAM) Sand and boulders method Large, long lasting VMs (boulders) 8 cores & 14 GB RAM, running for full duration 2 of them: RUBiS (ebay model) and RUBBoS (Slashdot model) Workload from scaled down Wikipedia traces Small, short lived VMs (sand) Blend of VMs running computationally expensive shell scrips (bursty) and Sudoku solvers (intensive) 12

13 Experimental Design (con t) Evaluate with 4 different scheduling techniques: Over KVM Let the KVM handle it, with over-booking No-Over KVM Let the KVM handle it, no over-booking Over-WF Worst Fit: choose least over-booked at the moment AaFS Afinity-Aware Fuzzy Scheduleer 13

14 Observations 14

15 Observations (con t) 15

16 Observations (con t) 16

17 Observations (con t) 17

18 Observations (con t) 18

19 Observations (con t) 19

20 Observations (con t) 20

CPU SCHEDULING RONG ZHENG

CPU SCHEDULING RONG ZHENG OVERVIEW Why scheduling? Non-preemptive vs Preemptive policies FCFS, SJF, Round robin, multilevel queues with feedback, guaranteed scheduling 2 SHORT-TERM, MID-TERM, LONG- TERM