Reconciling High Server U0liza0on and Sub-millisecond - - PowerPoint PPT Presentation

Reconciling ¡High ¡Server ¡U0liza0on ¡ and ¡ Sub-­‑millisecond ¡Quality-­‑of-­‑Service ¡

Jacob ¡Leverich ¡and ¡Christos ¡Kozyrakis, ¡ Stanford ¡University ¡ ¡ EuroSys ¡’14, ¡April ¡14th, ¡2014 ¡

1 ¡

0" 0.005" 0.01" 0.015" 0.02" 0.025" 0.03" 0.0" 0.1" 0.2" 0.3" 0.4" 0.5" 0.6" 0.7" 0.8" 0.9" 1.0" Frac%on(of(%me( CPU(u%liza%on(

Server ¡u0liza0on ¡is ¡low ¡

2 ¡

U0liza0on ¡at ¡Google ¡

[Barroso ¡and ¡Holzle, ¡2007] ¡ Industry ¡average ¡[McKinsey’09] ¡ Amazon ¡EC2 ¡[Liu, ¡CGC’11] ¡

Capital-­‑inefficient ¡ Power-­‑inefficient ¡

Why ¡so ¡low? ¡

• Diurnal ¡varia0on ¡
• Capacity ¡for ¡future ¡growth, ¡unexpected ¡spikes ¡
• Server/workload ¡mismatch ¡

Simple ¡solu5on: ¡ Cluster ¡Consolida5on ¡

3 ¡

Two ¡consolida0on ¡examples ¡

• Analy0cs ¡cluster ¡with ¡unused ¡memory ¡
• Memcached ¡cluster ¡with ¡unused ¡CPU ¡

4 ¡

Cores ¡ 20% ¡ Memory ¡ 70% ¡ Memcached? ¡ Cores ¡ 85% ¡ Memory ¡ 30% ¡ Analy0cs? ¡

Consolida0on ¡ ¡ ¡ ¡à ¡ ¡Poor ¡Performance ¡& ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Quality ¡of ¡Service ¡

• Interference ¡on ¡shared ¡resources ¡

– Cores, ¡caches, ¡memory, ¡storage, ¡network ¡ – QoS ¡viola5ons ¡in ¡low-­‑latency ¡applica5ons ¡

• Latency ¡correlated ¡with ¡revenue ¡[Mayer’06] ¡

¡ ¡

• Simple ¡solu0ons ¡lead ¡to ¡low-­‑u0liza0on ¡

– Don’t ¡co-­‑locate ¡work ¡with ¡low-­‑latency ¡services ¡ – Inflate ¡reserva0ons ¡to ¡reduce ¡co-­‑located ¡jobs ¡

5 ¡

6 ¡

Can ¡we ¡reconcile ¡high ¡u0liza0on ¡and ¡ good ¡quality ¡of ¡service? ¡

Project ¡MUTILATE: ¡ More ¡U5liza5on ¡ with ¡Low ¡Latency ¡

Contribu0ons ¡

• Iden0fied ¡key ¡QoS ¡vulnerabili0es ¡for ¡sub-­‑millisecond ¡services ¡

– Queuing ¡delay, ¡scheduling ¡delay, ¡thread ¡load ¡imbalance ¡

• Developed ¡best ¡prac0ces ¡to ¡maintain ¡good ¡QoS ¡

– Queuing ¡delay: ¡ ¡ ¡Interference-­‑aware ¡provisioning ¡ – Scheduling ¡delay: ¡ ¡ ¡Use ¡alterna0ves ¡to ¡CFS ¡ – Thread ¡load ¡imbalance: ¡Dynamically ¡share ¡connec0ons/requests ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡[or ¡pin ¡threads] ¡ – Network ¡interference: ¡NIC ¡receive-­‑flow ¡steering ¡

• 17-­‑52% ¡reduc0on ¡in ¡TCO ¡with ¡good ¡QoS ¡despite ¡interference ¡

¡ ¡ ¡

7 ¡

Focused ¡on ¡memcached ¡

• Low ¡nominal ¡latency: ¡100s ¡of ¡usecs ¡
• Sensi0ve ¡to ¡interference ¡
• Good ¡example ¡of ¡an ¡event-­‑based ¡service ¡

– Arch. ¡shared ¡by ¡REDIS, ¡node.js, ¡lighjpd, ¡nginx, ¡etc. ¡

• Focus ¡on ¡interference ¡due ¡to ¡consolida0on ¡

– Ignore ¡misbehaving ¡clients, ¡large ¡requests, ¡etc. ¡ [Shue, ¡OSDI’12, ¡“Pisces”] ¡

8 ¡

Life ¡of ¡a ¡memcached ¡request ¡

9 ¡

8 switch ¡

wire ¡

NIC ¡ 4 5 6 7

wire ¡

11 ¡ 3 9 8 IRQ ¡ Kernel ¡ Syscall ¡ NIC ¡

wire ¡

switch ¡ 1 3 TX ¡ Write ¡ 2 TCP/IP ¡ 11 ¡ User ¡ NIC ¡ 4 5 6 RX ¡ TCP/IP ¡ 9 ¡ 11 ¡ Epoll ¡ Read ¡ 13 ¡ Write ¡ 14 ¡ 15 ¡ TCP/IP ¡ TX ¡ 8 Schedule ¡ NIC ¡ 7 Ac0vate ¡ 12 ¡ Memcached ¡

Client ¡ Server ¡ Client ¡

GET ¡foo ¡ 10 ¡ libevent ¡ VALUE ¡foo ¡ bar ¡ END ¡

QoS ¡vulnerabili0es ¡

• Queuing ¡delay ¡

– Func0on ¡of ¡load ¡and ¡service ¡0me ¡

• Scheduling ¡delay ¡

– Wait ¡0me ¡and ¡context ¡switch ¡latency ¡

¡ ¡

3 9 8 IRQ ¡ Kernel ¡ Syscall ¡ 11 ¡ User ¡ NIC ¡ 4 5 6 RX ¡ TCP/IP ¡ 9 ¡ 11 ¡ Epoll ¡ Read ¡ 13 ¡ Write ¡ 14 ¡ 15 ¡ TCP/IP ¡ TX ¡ 8 Schedule ¡ NIC ¡ 7 Ac0vate ¡ 12 ¡ Memcached ¡

Server ¡

10 ¡ libevent ¡

10 ¡

~19-­‑21usecs ¡(unloaded) ¡ ~10usecs ¡ get ¡FOO ¡

Let’s ¡capacity ¡plan ¡a ¡cluster ¡

• Want ¡to ¡support ¡1B ¡queries/sec ¡total ¡

– Accounts ¡for ¡diurnal ¡varia0on, ¡unexpected ¡spikes ¡

(worst-­‑case ¡peak) ¡

– Must ¡maintain ¡low ¡latency ¡

• How ¡many ¡servers ¡do ¡we ¡need? ¡

11 ¡

Provisioning ¡for ¡Quality ¡of ¡Service ¡

12 ¡

~1M ¡QPS ¡

For ¡1B ¡QPS ¡we ¡need ¡ 1,000 ¡servers ¡@ ¡1M ¡QPS ¡

0" 100" 200" 300" 400" 500" 600" 700" 800" 900" 1000" 3 % " 8 % " 1 4 % " 1 9 % " 2 4 % " 3 % " 3 5 % " 4 1 % " 4 6 % " 5 1 % " 5 7 % " 6 2 % " 6 8 % " 7 3 % " 7 8 % " 8 4 % " 8 9 % " 9 5 % " 1 % " Latency((usecs)( Memcached(QPS((%(of(peak)( Average" 95th5%"

Provisioning ¡for ¡Quality ¡of ¡Service ¡

13 ¡

Provisioned ¡QPS ¡ Nominal ¡QPS ¡

Tons ¡of ¡spare ¡capacity! ¡ Can ¡I ¡make ¡use ¡of ¡it? ¡

Histogram ¡of ¡CPU ¡u5liza5on ¡@ ¡Google ¡[Barroso’07] ¡

0" 100" 200" 300" 400" 500" 600" 700" 800" 900" 1000" 3 % " 8 % " 1 4 % " 1 9 % " 2 4 % " 3 % " 3 5 % " 4 1 % " 4 6 % " 5 1 % " 5 7 % " 6 2 % " 6 8 % " 7 3 % " 7 8 % " 8 4 % " 8 9 % " 9 5 % " 1 % " Latency((usecs)( Memcached(QPS((%(of(peak)( Average" 95th5%"

Cluster ¡consolida0on ¡

• Memcached ¡cluster ¡

– 1,000 ¡servers, ¡30% ¡nominal ¡load ¡

• Analy0cs ¡cluster ¡

– 1,000 ¡servers, ¡50% ¡load, ¡best-­‑effort ¡batch ¡jobs ¡

• Can ¡we ¡combine ¡this ¡capacity? ¡

– Must ¡ensure ¡we ¡don’t ¡disturb ¡provisioned ¡QoS ¡ for ¡the ¡memcached ¡server ¡

14 ¡

0" 100" 200" 300" 400" 500" 600" 700" Latency((usecs)( Time((20(seconds)(

Latency ¡@ ¡80% ¡QPS ¡ Baseline ¡(no ¡interference) ¡

15 ¡

Avg ¡ 95th ¡

0" 500" 1,000" 1,500" 2,000" 2,500" 3,000" 3,500" 4,000" Latency((usecs)( Time((20(seconds)(

Latency ¡@ ¡80% ¡QPS ¡ with ¡471.omnetpp ¡

16 ¡

Old ¡ 95th ¡ 95th ¡ Old ¡ Avg ¡

Can’t ¡maintain ¡QoS ¡we ¡provisioned ¡for. ¡ This ¡is ¡why ¡workload ¡consolida5on ¡is ¡dangerous! ¡

Related ¡work ¡

• CPI2 ¡[EuroSys’13] ¡

– Punish ¡workload ¡causing ¡interference ¡

• Bubble-­‑Up, ¡Paragon ¡[MICRO’11, ¡ASPLOS’13] ¡

– Iden0fy ¡or ¡predict ¡workloads ¡that ¡interfere, ¡ don’t ¡consolidate ¡

• Manage ¡symptoms, ¡don’t ¡address ¡causes ¡

17 ¡

0" 100" 200" 300" 400" 500" 600" 700" 800" 900" 1000" 3 % " 8 % " 1 4 % " 1 9 % " 2 4 % " 3 % " 3 5 % " 4 1 % " 4 6 % " 5 1 % " 5 7 % " 6 2 % " 6 8 % " 7 3 % " 7 8 % " 8 4 % " 8 9 % " 9 5 % " 1 % " Latency((usecs)( Memcached(QPS((%(of(peak)( Average" 95th5%"

Latency ¡with ¡heavy ¡L3 ¡interference ¡

18 ¡

Provisioned ¡QPS ¡

0" 100" 200" 300" 400" 500" 600" 700" 800" 900" 1000" 3 % " 8 % " 1 4 % " 1 9 % " 2 4 % " 3 % " 3 5 % " 4 1 % " 4 6 % " 5 1 % " 5 7 % " 6 2 % " 6 8 % " 7 3 % " 7 8 % " 8 4 % " 8 9 % " 9 5 % " 1 % " Latency((usecs)( Memcached(QPS((%(of(peak)( Average" 95th5%" Average"(w/"L3"int.)" 95th5%"(w/"L3"int.)"

Latency ¡with ¡heavy ¡L3 ¡interference ¡ ¡

19 ¡

Provisioned ¡QPS ¡ 11 ¡ Read ¡ 13 ¡ Write ¡ 12 ¡ Memcached ¡ ~10usecs ¡ ~16usecs ¡

0" 100" 200" 300" 400" 500" 600" 700" 800" 900" 1000" 3 % " 8 % " 1 4 % " 1 9 % " 2 4 % " 3 % " 3 5 % " 4 1 % " 4 6 % " 5 1 % " 5 7 % " 6 2 % " 6 8 % " 7 3 % " 7 8 % " 8 4 % " 8 9 % " 9 5 % " 1 % " Latency((usecs)( Memcached(QPS((%(of(peak)( Average" 95th5%" Average"(w/"L3"int.)" 95th5%"(w/"L3"int.)"

Latency ¡with ¡heavy ¡L3 ¡interference ¡ ¡

20 ¡

Provisioned ¡QPS ¡

Interference-­‑aware ¡provisioning ¡

• Insight ¡

– Can ¡live ¡with ¡interference, ¡not ¡queuing ¡delay ¡ – Provisioning ¡at ¡80% ¡QPS ¡gave ¡us ¡no ¡margin ¡of ¡error ¡

• Reprovision ¡memcached ¡cluster ¡(60% ¡QPS ¡/ ¡server) ¡

– 1,300 ¡servers ¡for ¡1B ¡QPS ¡ – Immune ¡to ¡cache ¡interference, ¡free ¡to ¡co-­‑schedule ¡jobs ¡ – Plenty ¡of ¡spare ¡capacity ¡for ¡analy0cs ¡cluster ¡workload ¡

(1,000 ¡servers, ¡50% ¡load) ¡

• Combined ¡1,300 ¡servers ¡now ¡at ¡60% ¡nominal ¡u0liza0on ¡

– Achieve ¡good ¡QoS ¡with ¡interference, ¡even ¡at ¡peak! ¡

– 33% ¡fewer ¡servers ¡overall, ¡ 23% ¡less ¡power ¡consump0on, ¡ 17% ¡improvement ¡in ¡TCO ¡

21 ¡

0" 500" 1,000" 1,500" 2,000" 2,500" 3,000" 3,500" 4,000" Latency((usecs)( Time((20(seconds)(

Latency ¡@ ¡60% ¡QPS ¡ with ¡471.omnetpp ¡

22 ¡

95th ¡ @ ¡80% ¡ 95th ¡ @ ¡60% ¡

Scheduling ¡delay ¡

• Consolidated ¡cluster ¡(memcached ¡+ ¡analy0cs) ¡

– Analy0cs ¡= ¡“best ¡effort”, ¡only ¡use ¡spare ¡CPU ¡0me ¡ – Only ¡worry ¡about ¡context ¡switch ¡latency ¡

23 ¡

0" 100" 200" 300" 400" 500" 600" 700" 800" 900" 1000" 3%" 13%" 23%" 33%" 44%" 54%" 64%" 74%" 85%" 95%"

95th%%'Latency'(usecs)'

Memcached'QPS'(%'of'Peak)'

Memcached"alone"

Time-­‑sharing ¡with ¡memcached ¡

24 ¡

Core ¡

• Memc. ¡

SPEC ¡ NIC ¡

Time-­‑sharing ¡with ¡memcached ¡

• Context ¡switch ¡doesn’t ¡add ¡any ¡latency! ¡

25 ¡

Core ¡

• Memc. ¡

SPEC ¡ NIC ¡

0" 100" 200" 300" 400" 500" 600" 700" 800" 900" 1000" 3%" 13%" 23%" 33%" 44%" 54%" 64%" 74%" 85%" 95%"

95th%%'Latency'(usecs)'

Memcached'QPS'(%'of'Peak)'

Memcached"alone" 400.perlbench"

Time-­‑sharing ¡with ¡memcached ¡

• Context ¡switch ¡doesn’t ¡add ¡any ¡latency ¡
• Insensi0ve ¡to ¡workload ¡

26 ¡

0" 100" 200" 300" 400" 500" 600" 700" 800" 900" 1000" 3%" 13%" 23%" 33%" 44%" 54%" 64%" 74%" 85%" 95%"

95th%%'Latency'(usecs)'

Memcached'QPS'(%'of'Peak)'

Memcached"alone" 400.perlbench" 410.bwaves" 416.gamess" 429.mcf" 433.milc" 459.GemsFDTD" 450.soplex" 470.lbm" 471.omnetpp" 401.bzip2" 403.gcc" 434.zeusmp"

Scheduling ¡delay ¡

• Consolidated ¡cluster ¡(memcached ¡+ ¡analy0cs) ¡

– Analy0cs ¡= ¡“best ¡effort”, ¡only ¡use ¡spare ¡CPU ¡0me ¡ – Only ¡worry ¡about ¡context ¡switch ¡latency ¡

• No ¡worries! ¡
• Co-­‑scheduling ¡low-­‑latency ¡applica0ons ¡

– i.e. ¡memcached ¡+ ¡1ms ¡RPC ¡service ¡

27 ¡

CFS ¡can’t ¡guarantee ¡low ¡latency ¡

28 ¡

90 ¡ 80 ¡ 70 ¡ 60 ¡ 50 ¡ 40 ¡ 30 ¡ 20 ¡ 10 ¡ 10 ¡ 20 ¡ 30 ¡ 40 ¡ 50 ¡ 60 ¡ 70 ¡ 80 ¡ 90 ¡

Memcached ¡Load ¡(% ¡Peak ¡QPS) ¡ 1ms ¡RPC-­‑service ¡Load ¡(% ¡Peak ¡QPS) ¡

Achieved ¡QoS ¡w/ ¡two ¡low-­‑latency ¡workloads ¡ Both ¡meet ¡QoS ¡ 1ms ¡service ¡fails ¡ Memcached ¡fails ¡ Both ¡fail ¡to ¡meet ¡QoS ¡ QoS ¡requirement ¡ = ¡95th ¡< ¡5x ¡low-­‑load ¡95th ¡

Bad ¡QoS ¡with ¡minor ¡ interference! ¡

0" 2000" 4000" 6000" 8000" 10000" 12000" 3%" 8%" 13%" 18%" 24%" 29%" 34%" 39%" 45%" 50%" 55%" 61%" 66%" 71%" 76%" 82%" 87%" 92%" 97%" 95th%%'Latency'(usecs)' Memcached'QPS'(%'of'Peak)' No"Interference" CFS"

Time-­‑sharing ¡with ¡a ¡periodic ¡task ¡

• Periodic ¡task ¡runs ¡6ms ¡every ¡48ms ¡(12% ¡load) ¡

– 50/50 ¡CPU ¡share ¡

29 ¡

Huge ¡QoS ¡viola5ons, ¡ even ¡at ¡low ¡load! ¡

Interference ¡w/ ¡CFS ¡ No ¡interference ¡

CFS: ¡Completely ¡Fair ¡Scheduler ¡

• Tasks ¡sorted ¡by ¡run0me ¡along ¡a ¡0meline ¡

– Run ¡the ¡earliest ¡task ¡whenever ¡you ¡reschedule ¡ – When ¡a ¡task ¡T ¡wakes ¡up, ¡assign ¡its ¡run0me ¡as: ¡ ¡run0me(T) ¡= ¡max(min(run0me(*)) ¡– ¡L, ¡run0me(T)) ¡

30 ¡

A ¡B ¡

0me ¡ ¡

L ¡ C ¡

• 1. Task ¡B ¡wakes ¡up ¡
• 2. B ¡preempts ¡A, ¡forces ¡A ¡to ¡wait ¡while ¡it ¡runs ¡

12ms ¡by ¡default! ¡

Good ¡for ¡desktop ¡ Bad ¡for ¡datacenters! ¡

0" 2000" 4000" 6000" 8000" 10000" 12000" 3%" 8%" 13%" 18%" 24%" 29%" 34%" 39%" 45%" 50%" 55%" 61%" 66%" 71%" 76%" 82%" 87%" 92%" 97%" 95th%%'Latency'(usecs)' Memcached'QPS'(%'of'Peak)' No"Interference" CFS"

31 ¡

Interference ¡w/ ¡CFS ¡

Square ¡

0me ¡ ¡

Memcached ¡

No ¡interference ¡

0" 2000" 4000" 6000" 8000" 10000" 12000" 3%" 8%" 13%" 18%" 24%" 29%" 34%" 39%" 45%" 50%" 55%" 61%" 66%" 71%" 76%" 82%" 87%" 92%" 97%" 95th%%'Latency'(usecs)' Memcached'QPS'(%'of'Peak)' No"Interference" CFS"

32 ¡

Huge ¡QoS ¡viola5ons, ¡ even ¡at ¡low ¡load! ¡

Interference ¡w/ ¡CFS ¡

Square ¡

0me ¡ ¡

Memcached ¡

No ¡interference ¡

BVT: ¡Borrowed ¡virtual ¡0me ¡[Duda’99] ¡

• Same ¡basic ¡principle ¡as ¡CFS, ¡plus ¡

– Assign ¡each ¡task ¡a ¡“warp” ¡value ¡ – Schedule ¡based ¡on ¡“effec0ve” ¡run0me: ¡ ¡effec0ve ¡run0me(T) ¡= ¡run0me(T) ¡– ¡warp(T) ¡

33 ¡

A ¡ B ¡ B’ ¡ 0me ¡ ¡ L ¡ warp(B) ¡= ¡0 ¡ A’ ¡ Task ¡A ¡not ¡interrupted ¡by ¡B ¡waking ¡up ¡ ¡

• Short-­‑term ¡preemp0on ¡bias ¡
• Long-­‑term ¡throughput ¡fairness ¡

warp(A) ¡> ¡L ¡

0" 2000" 4000" 6000" 8000" 10000" 12000" 3%" 8%" 13%" 18%" 24%" 29%" 34%" 39%" 45%" 50%" 55%" 61%" 66%" 71%" 76%" 82%" 87%" 92%" 97%" 95th%%'Latency'(usecs)' Memcached'QPS'(%'of'Peak)' No"Interference" CFS" BVT"

BVT: ¡Borrowed ¡virtual ¡0me ¡[Duda’99] ¡

• Periodic ¡task ¡runs ¡6ms ¡every ¡48ms ¡(12% ¡load) ¡

– 50/50 ¡CPU ¡share ¡

34 ¡

50% ¡share ¡

No ¡QoS ¡viola5ons ¡ at ¡fair ¡load ¡

Interference ¡w/ ¡CFS ¡ Interference ¡w/ ¡BVT ¡ No ¡interference ¡

BVT: ¡Good ¡QoS ¡for ¡both ¡services ¡

35 ¡

90 ¡ 80 ¡ 70 ¡ 60 ¡ 50 ¡ 40 ¡ 30 ¡ 20 ¡ 10 ¡ 10 ¡ 20 ¡ 30 ¡ 40 ¡ 50 ¡ 60 ¡ 70 ¡ 80 ¡ 90 ¡

Memcached ¡Load ¡(% ¡Peak ¡QPS) ¡ 1ms ¡RPC-­‑service ¡Load ¡(% ¡Peak ¡QPS) ¡

Achieved ¡QoS ¡w/ ¡two ¡low-­‑latency ¡workloads ¡ Both ¡meet ¡QoS ¡ 1ms ¡service ¡fails ¡ Memcached ¡fails ¡ Both ¡fail ¡to ¡meet ¡QoS ¡ QoS ¡requirement ¡ = ¡95th ¡< ¡5x ¡low-­‑load ¡95th ¡

BVT ¡patch ¡to ¡Linux ¡3.5.0 ¡

• Simple ¡extension ¡to ¡CFS ¡
• Implemented ¡at ¡container ¡group ¡level ¡

– Warp ¡specified ¡per ¡cgroup ¡in ¡cgroupfs ¡ – Defaults ¡to ¡normal ¡CFS ¡behavior ¡

• hjps://gist.github.com/leverich/5913713 ¡

¡include/linux/sched.h ¡ ¡ ¡| ¡ ¡ ¡ ¡8 ¡++++++ ¡

¡init/Kconfig ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡| ¡ ¡ ¡14 ¡+++++++++++ ¡ ¡kernel/sched/core.c ¡ ¡ ¡ ¡ ¡| ¡ ¡ ¡31 ¡+++++++++++++++++++++++ ¡ ¡kernel/sched/fair.c ¡ ¡ ¡ ¡ ¡| ¡ ¡ ¡93 ¡++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++-­‑-­‑-­‑ ¡ ¡kernel/sched/features.h ¡| ¡ ¡ ¡ ¡2 ¡++ ¡ ¡kernel/sched/sched.h ¡ ¡ ¡ ¡| ¡ ¡ ¡ ¡4 ¡+++ ¡ ¡kernel/sysctl.c ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡| ¡ ¡ ¡ ¡9 ¡+++++++ ¡ ¡7 ¡files ¡changed, ¡158 ¡insertions(+), ¡3 ¡deletions(-­‑) ¡

36 ¡

Contribu0ons ¡

• Iden0fied ¡key ¡QoS ¡vulnerabili0es ¡for ¡sub-­‑millisecond ¡services ¡

– Queuing ¡delay, ¡scheduling ¡delay, ¡thread ¡load ¡imbalance ¡

• Developed ¡best ¡prac0ces ¡to ¡maintain ¡good ¡QoS ¡

– Queuing ¡delay: ¡ ¡ ¡Interference-­‑aware ¡provisioning ¡ – Scheduling ¡delay: ¡ ¡ ¡Use ¡alterna0ves ¡to ¡CFS ¡ – Thread ¡load ¡imbalance: ¡Dynamically ¡share ¡connec0ons/requests ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡[or ¡pin ¡threads] ¡ – Network ¡interference: ¡NIC ¡receive-­‑flow ¡steering ¡

• Ques0on: ¡“Can ¡we ¡reconcile ¡high ¡u0liza0on ¡and ¡

¡ ¡ ¡ ¡good ¡quality ¡of ¡service?” ¡ ¡ ¡

37 ¡

Contribu0ons ¡

• Iden0fied ¡key ¡QoS ¡vulnerabili0es ¡for ¡sub-­‑millisecond ¡services ¡

– Queuing ¡delay, ¡scheduling ¡delay, ¡thread ¡load ¡imbalance ¡

• Developed ¡best ¡prac0ces ¡to ¡maintain ¡good ¡QoS ¡

– Queuing ¡delay: ¡ ¡ ¡Interference-­‑aware ¡provisioning ¡ – Scheduling ¡delay: ¡ ¡ ¡Use ¡alterna0ves ¡to ¡CFS ¡ – Thread ¡load ¡imbalance: ¡Dynamically ¡share ¡connec0ons/requests ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡[or ¡pin ¡threads] ¡ – Network ¡interference: ¡NIC ¡receive-­‑flow ¡steering ¡

• Ques0on: ¡“Can ¡we ¡reconcile ¡high ¡u0liza0on ¡and ¡

¡ ¡ ¡ ¡good ¡quality ¡of ¡service?” ¡ ¡ ¡

38 ¡

Thanks! ¡

39 ¡

40 ¡

Backup ¡Slides ¡

41 ¡

Mu0late: ¡ A ¡memcached ¡load ¡generator ¡

• hjp://github.com/leverich/mu0late ¡
• Distributed ¡and ¡epoll-­‑based ¡
• High ¡performance ¡(millions ¡of ¡QPS) ¡
• Arbitrary ¡intertransmission ¡dist. ¡(QPS ¡control) ¡
• Latency ¡sampled ¡at ¡1 ¡kHz ¡by ¡independent ¡open-­‑loop ¡

connec0ons ¡(no ¡client-­‑side ¡queuing ¡delay ¡due ¡to ¡load ¡ genera0on), ¡UDP ¡or ¡TCP ¡

• Arbitrary ¡value/key ¡size ¡distribu0ons ¡(can ¡replay ¡

“Workload ¡Analysis ¡of ¡a ¡Large-­‑Scale ¡Key-­‑Value ¡ Store” ¡[A0koglu ¡et ¡al., ¡SIGMETRICS’12]) ¡

42 ¡

User% 17%% System% 52%% So0IRQ% 31%%

Time-­‑sharing ¡a ¡core ¡

– Memcached ¡runs ¡o{en ¡enough ¡to ¡keep ¡cache ¡ warm ¡ – TLB ¡flush ¡has ¡minimal ¡impact ¡

43 ¡

Memcached ¡CPU ¡0me ¡ Only ¡part ¡affected ¡ by ¡TLB ¡flush ¡

12,000-­‑node ¡Google ¡cluster ¡ [Reiss, ¡SOCC’12] ¡

44 ¡

~0.5 ¡PB ¡of ¡memory ¡ ~#50, ¡top ¡SC ¡list ¡

0" 0.05" 0.1" 0.15" 0.2" 0.25" 0.3" 0.35" 0.4" 4 . p e r l b e n c h " 4 1 . b w a v e s " 4 3 . g c c " 4 3 4 . z e u s m p " 4 3 3 . m i l c " 4 1 6 . g a m e s s " 4 2 9 . m c f " 4 1 . b z i p 2 " 4 7 . l b m " 4 5 . s

• p

l e x " 4 5 9 . G e m s F D T D " 4 7 1 .

• m

n e t p p " Normalized+Performance+

Performance+of+background+task+

Co-­‑scheduled ¡task ¡incurs ¡the ¡overhead ¡

Inefficiency ¡ Bejer ¡trade-­‑off ¡than ¡3x ¡over-­‑reserva0on ¡

45 ¡

Low ¡u0liza0on ¡outside ¡Google ¡

• Mozilla: ¡10% ¡
• McKinsey ¡’08: ¡Industry-­‑wide ¡~6% ¡
• Gartner ¡’10: ¡Industry-­‑wide ¡12% ¡
• Tata ¡[HPCA’10]: ¡12.5% ¡
• Amazon ¡[Liu ¡CGC’11]: ¡7.3% ¡

46 ¡

Diurnal ¡varia0on ¡at ¡Facebook ¡[A0koglu’12] ¡

47 ¡

Spare ¡capacity ¡

Queuing ¡Delay ¡

• Systemtap ¡to ¡trace ¡kernel/memcached ¡at ¡run0me ¡

– We ¡track ¡individual ¡connec0ons ¡to ¡record ¡per-­‑request ¡latency ¡

Who ¡ What ¡ Low ¡load ¡ Overload ¡

Server ¡

RX ¡ 0.9us ¡ 1us ¡ TCP/IP ¡ 4.7us ¡ 4us ¡ epoll() ¡return ¡ 3.9us ¡ 2778us ¡ libevent ¡ 2.4us ¡ 3074us ¡ read() ¡call/ret ¡ 2.5us ¡ 5us ¡ ¡ ¡ ¡ ¡memcached ¡ 2.5us ¡ 2us ¡ write()+TX ¡ 4.6us ¡ 4us ¡ Total ¡ 21.5us ¡ 5872us ¡

Client ¡

End-­‑to-­‑End ¡ 49.8us ¡ 6011us ¡

48 ¡

Queuing ¡Delay ¡

• Systemtap ¡to ¡trace ¡kernel/memcached ¡at ¡run0me ¡

– We ¡track ¡individual ¡connec0ons ¡to ¡record ¡per-­‑request ¡latency ¡

Who ¡ What ¡ Low ¡load ¡ Overload ¡

Server ¡

RX ¡ 0.9us ¡ 1us ¡ TCP/IP ¡ 4.7us ¡ 4us ¡ epoll() ¡return ¡ 3.9us ¡ 2778us ¡ libevent ¡ 2.4us ¡ 3074us ¡ read() ¡call/ret ¡ 2.5us ¡ 5us ¡ ¡ ¡ ¡ ¡memcached ¡ 2.5us ¡ 2us ¡ write()+TX ¡ 4.6us ¡ 4us ¡ Total ¡ 21.5us ¡ 5872us ¡

Client ¡

End-­‑to-­‑End ¡ 49.8us ¡ 6011us ¡

49 ¡

Queue ¡#1: ¡Epoll ¡ready ¡list ¡ Queue ¡#2: ¡Libevent ¡ ¡internal ¡event ¡list ¡

Latency ¡with ¡heavy ¡L3 ¡interference ¡

50 ¡

Who ¡ What ¡ Low ¡load ¡ Overload ¡ + ¡L3 ¡Int. ¡

Server ¡

RX ¡ 0.9us ¡ 1us ¡ 1us ¡ TCP/IP ¡ 4.7us ¡ 4us ¡ 4us ¡ epoll() ¡return ¡ 3.9us ¡ 2778us ¡ 3780us ¡ libevent ¡ 2.4us ¡ 3074us ¡ 4545us ¡ read() ¡call/ret ¡ 2.5us ¡ 5us ¡ 7us ¡ ¡ ¡ ¡ ¡memcached ¡ 2.5us ¡ 2us ¡ 4us ¡ write()+TX ¡ 4.6us ¡ 4us ¡ 5us ¡ Total ¡ 21.5us ¡ 5872us ¡ 8349us ¡

Client ¡

End-­‑to-­‑End ¡ 49.8us ¡ 6011us ¡ 8460us ¡ TX-­‑to-­‑RX ¡ 36us ¡

Switch ¡

RX-­‑to-­‑TX ¡ 3us ¡

Systemtap ¡

• Kprobe-­‑based ¡dynamic ¡instrumenta0on ¡of ¡

Linux ¡kernel ¡(like ¡DTrace) ¡

probe kernel.function( "tcp_rcv_established@net/ipv4/tcp_input.c” ).return { tstamps[$sk,"tcpip_rx"] = gettimeofday_ns() }

51 ¡

Mul0-­‑queue ¡NICs: ¡Receive-­‑Side ¡Scaling ¡

52 ¡

Core ¡1 ¡ Core ¡2 ¡ Core ¡3 ¡ Core ¡4 ¡ App ¡A ¡ App ¡A ¡ App ¡B ¡ App ¡B ¡ NIC ¡ RX ¡hash ¡

• 1. Cache ¡misses ¡and ¡IPI ¡
• 2. Collateral ¡damage ¡

from ¡interrupt ¡

Network ¡interrupt ¡interference ¡

• Memcached ¡on ¡socket ¡#1, ¡D-­‑ITG ¡on ¡socket ¡#2 ¡
• Mul0-­‑queue ¡NICs ¡with ¡receive-­‑side ¡scaling ¡spray ¡

interrupts ¡across ¡all ¡cores ¡

– Necessary ¡to ¡handle ¡10GbE ¡packet ¡rates ¡ – Can ¡cause ¡massive ¡interference, ¡even ¡at ¡low ¡B/W ¡

53 ¡

NIC Configuration Network Traffic 1Gbps

Receive-side scaling (rx hashing) 24% Memcached ¡QPS ¡loss ¡ due ¡to ¡concurrent ¡ network ¡traffic ¡

Receive-­‑Flow ¡Steering ¡

54 ¡

Core ¡1 ¡ Core ¡2 ¡ Core ¡3 ¡ Core ¡4 ¡ App ¡A ¡ App ¡A ¡ App ¡B ¡ App ¡B ¡ NIC ¡ RX ¡hash ¡

• 1. Few ¡cache ¡misses ¡
• 2. No ¡collateral ¡damage ¡

Receive-­‑flow ¡steering ¡

• Largely ¡mi0gated ¡by ¡receive-­‑flow ¡steering ¡

– Send ¡interrupts ¡to ¡the ¡core ¡responsible ¡for ¡a ¡flow ¡ – QoS ¡benefits ¡unreported ¡in ¡literature ¡

• Available ¡in ¡Mellanox ¡and ¡Intel ¡NICs ¡

– Intel’s ¡IXGBE ¡driver ¡implements ¡“RX ¡follows ¡TX” ¡policy ¡ (not ¡in ¡mainline ¡Linux) ¡

55 ¡

NIC Configuration Network Traffic 1Gbps

Receive-side scaling (rx hashing) 24% Receive-flow steering (rx follows tx) 1% Memcached ¡QPS ¡loss ¡ due ¡to ¡concurrent ¡ network ¡traffic ¡

Problems ¡with ¡sta0c ¡connec0on ¡ assignment ¡

• Queuing ¡delay ¡due ¡to… ¡

– Unbalanced ¡# ¡of ¡clients ¡ – Hot/cold ¡clients ¡ – Unbalanced ¡CPU ¡performance ¡ ¡(i.e. ¡cache ¡int.) ¡

• Scheduling ¡delay ¡due ¡to… ¡

– Co-­‑scheduled ¡work ¡ – Mismatched ¡# ¡of ¡threads ¡and ¡CPUs ¡

• Tail ¡latency ¡suffers ¡if ¡only ¡one ¡thread ¡affected! ¡

56 ¡

0" 1000" 2000" 3000" 4000" 5000" 6000" 7000" 8000" 9000" 10000" "50,000"" "100,000"" "150,000"" "200,000"" "250,000"" "300,000"" "350,000"" "400,000"" "450,000"" "500,000"" "550,000"" "600,000"" "650,000"" "700,000"" "750,000"" "800,000"" "850,000"" "900,000"" "950,000"" "1,000,000"" !Latency!(usecs)! Memcached!QPS!

Latency!vs.!QPS!(#!threads!=!#!cores!+!1)!

TCP"(95th3%)" TCP"(50th3%)"

Latency ¡with ¡# ¡threads ¡= ¡# ¡cores ¡+ ¡1 ¡

57 ¡

At ¡least ¡one ¡core ¡has ¡ >1 ¡thread ¡at ¡all ¡0mes! ¡

0" 1000" 2000" 3000" 4000" 5000" 6000" 7000" 8000" 9000" 10000" "50,000"" "100,000"" "150,000"" "200,000"" "250,000"" "300,000"" "350,000"" "400,000"" "450,000"" "500,000"" "550,000"" "600,000"" "650,000"" "700,000"" "750,000"" "800,000"" "850,000"" "900,000"" "950,000"" "1,000,000"" !Latency!(usecs)! Memcached!QPS!

Latency!vs.!QPS!(#!threads!=!#!cores)!

TCP"(95th3%)" TCP"(50th3%)"

Same ¡result ¡with ¡# ¡threads ¡= ¡# ¡cores! ¡

58 ¡

Due ¡to ¡spurious ¡thread ¡migra5on! ¡ (i.e. ¡affine ¡wakeups, ¡ wakeup ¡load ¡balancing, ¡ background ¡daemons) ¡

Occasionally ¡ 2 ¡threads ¡on ¡1 ¡core, ¡

• nly ¡impacts ¡tail ¡latency ¡

0" 1000" 2000" 3000" 4000" 5000" 6000" 7000" 8000" 9000" 10000" "50,000"" "100,000"" "150,000"" "200,000"" "250,000"" "300,000"" "350,000"" "400,000"" "450,000"" "500,000"" "550,000"" "600,000"" "650,000"" "700,000"" "750,000"" "800,000"" "850,000"" "900,000"" "950,000"" "1,000,000"" !95th&%!Latency!(usecs)! Memcached!QPS!

Latency!vs.!QPS!(#!threads!=!#!cores)!

TCP" TCP+Pin"

Pin ¡threads ¡to ¡prevent ¡migra0ons ¡

59 ¡

Pin ¡= ¡sched_setaffinity() ¡to ¡ assign ¡threads ¡to ¡specific ¡cores ¡

0" 1000" 2000" 3000" 4000" 5000" 6000" 7000" 8000" 9000" 10000" "50,000"" "100,000"" "150,000"" "200,000"" "250,000"" "300,000"" "350,000"" "400,000"" "450,000"" "500,000"" "550,000"" "600,000"" "650,000"" "700,000"" "750,000"" "800,000"" "850,000"" "900,000"" "950,000"" "1,000,000"" !95th&%!Latency!(usecs)! Memcached!QPS!

Latency!vs.!QPS!(#!threads!=!#!cores)!

TCP" TCP+Pin" UDP"

Interes0ng ¡UDP ¡behavior ¡

60 ¡

Most ¡load ¡generated ¡w/ ¡TCP, ¡ UDP ¡latency ¡sampled ¡at ¡1kHz ¡ (dozens ¡of ¡UDP ¡client ¡conns.) ¡

0" 1000" 2000" 3000" 4000" 5000" 6000" 7000" 8000" 9000" 10000" "50,000"" "100,000"" "150,000"" "200,000"" "250,000"" "300,000"" "350,000"" "400,000"" "450,000"" "500,000"" "550,000"" "600,000"" "650,000"" "700,000"" "750,000"" "800,000"" "850,000"" "900,000"" "950,000"" "1,000,000"" !Latency!(usecs)! Memcached!QPS!

Latency!vs.!QPS!(#!threads!=!#!cores!+!1)!

TCP"(95th3%)" TCP"(50th3%)" UDP"(95th3%)"

Interes0ng ¡UDP ¡behavior ¡

61 ¡

At ¡least ¡one ¡core ¡has ¡ >1 ¡thread ¡at ¡all ¡0mes! ¡

Memcached ¡UDP ¡handling ¡

Listen ¡ Thread ¡ Worker ¡ Thread ¡ Worker ¡ Thread ¡ Worker ¡ Thread ¡ Worker ¡ Thread ¡ Epoll ¡Set ¡ Epoll ¡Set ¡ Epoll ¡Set ¡ Epoll ¡Set ¡

UDP ¡

62 ¡

Core ¡1 ¡ Core ¡2 ¡ Core ¡2 ¡ Core ¡3 ¡

• Dynamically ¡load ¡balanced! ¡
• Poor ¡QPS ¡due ¡to ¡lock ¡conten0on ¡on ¡UDP ¡socket ¡

– Mul0ple ¡UDP ¡sockets ¡might ¡reintroduce ¡QoS ¡problem ¡

UDP ¡ UDP ¡ UDP ¡

More ¡Related ¡Work ¡

• Deadline ¡scheduling ¡

– Liu ¡and ¡Layland ¡[JACM’1973], ¡seminal ¡results ¡ – AQuoSA ¡[SPE’08], ¡EDF ¡w/ ¡dynamic ¡reserva0ons, ¡ SCHED_DEADLINE ¡ – We ¡should ¡schedule ¡events, ¡not ¡processes! ¡

• Ultra-­‑low ¡latency ¡services ¡

– RAMCloud ¡[OSR’10], ¡Chronos ¡[SOCC’12] ¡ – User-­‑level ¡networking, ¡bypass ¡OS! ¡ – Must ¡reconcile ¡provisioned ¡vs. ¡nominal ¡QPS ¡

63 ¡

Consolida0on ¡related ¡work ¡

• Don’t ¡run ¡interfering ¡jobs ¡together ¡

– Bubble-­‑Up ¡[Mars, ¡MICRO’11] ¡ – Paragon ¡[Delimitrou, ¡ASPLOS’13] ¡ – Don’t ¡address ¡the ¡root ¡cause ¡of ¡QoS ¡problems ¡

• Network ¡QoS: ¡HULL ¡[NSDI’12] ¡
• Hardware ¡interference ¡mi0ga0on ¡

– Vantage ¡[Sanchez, ¡ISCA’11] ¡ – SMT ¡QoS ¡[Herdrich, ¡HotPar’12] ¡ – Reduce ¡amount ¡of ¡interference, ¡don’t ¡eliminate ¡

64 ¡

Par00on/Aggregate ¡Workloads ¡

Overall ¡latency ¡dominated ¡by ¡the ¡“tail” ¡ Long ¡latency ¡= ¡lost ¡revenue ¡

Aggregator ¡ Leaf ¡ Leaf ¡ Leaf ¡ Leaf ¡

. ¡. ¡. ¡

Query: ¡“Funniest ¡movie ¡ever” ¡ Clueless ¡(0.6) ¡

65 ¡

Data ¡ Data ¡ Data ¡ Data ¡

Other ¡schedulers ¡do ¡bejer ¡

66 ¡

Completely ¡Fair ¡ Scheduler ¡ POSIX ¡Real5me ¡ + ¡Bandwidth ¡Limit ¡ BVT ¡[Duda’99] ¡ + ¡Grace ¡Period ¡

Feature ¡

Reserva5ons ¡

✔ ¡ ✔ ¡ ✔ ¡

Configurable ¡ preemp5on ¡

✖ ¡ ✔ ¡ ✔ ¡

Work ¡ conserving ¡

✔ ¡ ✖ ¡ ✔ ¡

Memcached ¡ 1ms ¡latency-­‑sensi0ve ¡task ¡

Achieved ¡QoS ¡with ¡2 ¡low-­‑latency ¡tasks ¡

Alterna0ve ¡event-­‑handling ¡paradigms ¡

• Sockets ¡shared ¡across ¡event ¡sets ¡

– Be ¡mindful ¡of ¡socket ¡lock ¡conten0on… ¡ – Thundering ¡herd; ¡don’t ¡put ¡socket ¡in ¡EVERY ¡set ¡

• Event ¡sets ¡shared ¡across ¡threads ¡

– Edge-­‑triggered ¡or ¡EPOLL_ONESHOT ¡to ¡avoid ¡thundering ¡herd ¡ – Not ¡supported ¡by ¡libevent ¡ – Be ¡mindful ¡of ¡event ¡set ¡lock ¡conten0on… ¡

• Connec0on ¡stealing/load ¡balancing ¡

– Pisces ¡[Shue ¡et ¡al., ¡OSDI’12] ¡

• Event ¡stealing ¡

– Maintain ¡thread-­‑safe ¡queue ¡of ¡events ¡returned ¡by ¡epoll_wait() ¡ – Steal ¡events ¡from ¡neighbors ¡when ¡idle ¡

• Comparison ¡= ¡future ¡work ¡J ¡

67 ¡

fini ¡

68 ¡