ALMA - GC-assisted JVM Live Migration for Java Server Applications - - PowerPoint PPT Presentation

alma gc assisted jvm live migration for java server
SMART_READER_LITE
LIVE PREVIEW

ALMA - GC-assisted JVM Live Migration for Java Server Applications - - PowerPoint PPT Presentation

ALMA - GC-assisted JVM Live Migration for Java Server Applications Rodrigo Bruno, Paulo Ferreira {rodrigo.bruno,paulo.ferreira}@inesc-id.pt INESC-ID - Instituto Superior Tcnico, ULisboa Middleware16@Trento JVM Live Migration (real


slide-1
SLIDE 1

ALMA - GC-assisted JVM Live Migration for Java Server Applications

Rodrigo Bruno, Paulo Ferreira {rodrigo.bruno,paulo.ferreira}@inesc-id.pt INESC-ID - Instituto Superior Técnico, ULisboa Middleware’16@Trento

slide-2
SLIDE 2

2

JVM Live Migration (real scenario)

slide-3
SLIDE 3

2

JVM Live Migration (real scenario)

slide-4
SLIDE 4

2

JVM Live Migration (real scenario)

slide-5
SLIDE 5

2

JVM Live Migration (real scenario)

slide-6
SLIDE 6

2

JVM Live Migration (real scenario)

slide-7
SLIDE 7

2

JVM Live Migration (real scenario)

slide-8
SLIDE 8

2

JVM Live Migration (real scenario)

slide-9
SLIDE 9

3

Goals

Support JVM live migration with: ✓ Low total migration time; ✓ Low application downtime; ✓ Low application throughput impact; ✓ Low resource overhead; ✓ No programmer intervention; ✓ No special hardware/OS.

slide-10
SLIDE 10

4

JVM Live Migration (challenges)

! Keep migration and application down times short; ! Avoid high resource (eg. CPU, Network) overhead; ! Avoid application slowdown / performance overhead; ! Cope with fast moving / allocation intensive applications; ! Cope with low/congested network bandwidths;

slide-11
SLIDE 11

Drawbacks of Current Solutions

5

ㄨ Force application throttling (Clark et. al, 2005); ㄨ Rely on high speed networks (Huang et. al, 2007); ㄨ Fail to determine the live Working Set (Hou et. al, 2015); ㄨ When only a process is targeted: ○ the whole system VM is migrated (containing multiple processes and kernel); ○ the whole process image is migrated (including unreachable data). ㄨ Force full GC before migration (Kawachiya et. al, 2007);

slide-12
SLIDE 12

ALMA - Key Insights

6

  • Migrate only the process (JVM)

■ avoid kernel, other processes, etc;

  • Use GC to reduce the snapshot size;
  • Dynamically minimize the size of the memory to migrate

■ migrate only live objects ■ only collect regions which can be collected faster than transmitted through the network.

This leads to small (with almost only live data) snapshots.

slide-13
SLIDE 13

Presentation Overview

  • GC background
  • ALMA

○ Collection Set ○ Migration Workflow ○ Architecture

  • Implementation
  • Evaluation

○ App. Downtime ○ Total Migration Time ○ App. Throughput ○ Network Bandwidth Usage

7

slide-14
SLIDE 14

GC Background

8

  • Parallel Scavenge (old):

○ Spaces: Eden, Survivor, Old ○ Each space is a continuous memory block; ○ Young collection (only Eden and Survivor spaces), or ○ Full collection (all spaces)

  • G1 (most recent OpenJDK

garbage collector): ○ Heap is divided into Regions (E,S,H,O) ○ Set of regions to collect: Collection Set (CS)

slide-15
SLIDE 15

ALMA: Collection Set

9

  • Amount of data included in the snapshot:

Minimize size of snapshot

slide-16
SLIDE 16

ALMA: Collection Set

9

  • Amount of data included in the snapshot:
  • Total GCCost (time) for collecting the Collection Set (CS):

Minimize size of snapshot

slide-17
SLIDE 17

ALMA: Collection Set

10

  • Migration Cost (time) for migrating JVM:

Minimize size of snapshot

slide-18
SLIDE 18

ALMA: Collection Set

10

  • Migration Cost (time) for migrating JVM:
  • GC Rate (amount of dead space collected per amount
  • f time):

Minimize size of snapshot

slide-19
SLIDE 19

ALMA: Collection Set

10

  • Migration Cost (time) for migrating JVM:
  • GC Rate (amount of dead space collected per amount
  • f time):
  • CS is the group of regions with GC Rate inferior to the

Network Bandwidth:

Minimize size of snapshot

slide-20
SLIDE 20

ALMA: Collection Set

10

  • Migration Cost (time) for migrating JVM:
  • GC Rate (amount of dead space collected per amount
  • f time):
  • CS is the group of regions with GC Rate inferior to the

Network Bandwidth: Set of regions which can be collected faster than transmitted through the network:

  • Without collection, migration cost is X
  • With collection, migration cost is X’ + GCCost

X > X’ + GCCost

slide-21
SLIDE 21

ALMA: Migration Workflow

11 Steps: 1. Prepare Snapshot 2. Build and Collect CS (Migr. Aware GC) 3. Return Free Mappings 4. Send Free Mappings to Coordinator 5. Checkpoint JVM 6. Send Snapshot 7. Stop JVM, incremental snapshot 8. Send final snapshot 9. Restore JVM from snapshot.

slide-22
SLIDE 22

ALMA: Architecture

12 Components:

  • Application: target application to migrate;
  • Agent: analyzes the JVM;
  • Coordinator: coordinates migration;
  • Dump: takes JVM snapshots;
  • Img Proxy: sends snapshot;
  • Img Cache: caches snapshot;
  • Restore: restores JVM from snapshots;
slide-23
SLIDE 23

Implementation

13

  • ALMA augmented G1 to support Migration Aware GC;
  • Coordinator is implemented by extending CRIU to support

remote migration. ALMA added two new components to CRIU: ○ Image Proxy - sends snapshot to the destination site; ○ Image Cache - caches snapshot in the destination site; ○ A patch is being iteratively refined to add both components to CRIU.

slide-24
SLIDE 24

Evaluation

14

  • Evaluate ALMA’s performance compared to:

○ CRIU - Checkpoint and Restore for Linux; ○ JAVMM (Hou et. al, 2015) - Extends Xen to migrate Java

  • applications. It simply collects the young generation before

migration; ○ ALMA-PS - Similar to JAVMM but based on CRIU.

  • Environment:

○ OpenStack VMs with 4vCPUs and 4GB RAM ○ DaCapo and SpecJVM2008 benchmark suites

slide-25
SLIDE 25

Evaluation

14

  • Evaluate ALMA’s performance compared to:

○ CRIU - Checkpoint and Restore for Linux ○ JAVMM (Hou et. al, 2015) - Extends Xen to migrate Java

  • applications. It simply collects the young generation before

migration. ○ ALMA-PS - Similar to JAVMM but based on CRIU;

  • Environment:

○ OpenStack VMs with 4vCPUs and 4GB RAM ○ DaCapo and SpecJVM2008 benchmark suites Our Baseline

slide-26
SLIDE 26

Evaluation

14

  • Evaluate ALMA’s performance compared to:

○ CRIU - Checkpoint and Restore for Linux ○ JAVMM (Hou et. al, 2015) - Extends Xen to migrate Java

  • applications. It simply collects the young generation before

migration. ○ ALMA-PS - Similar to JAVMM but based on CRIU;

  • Environment:

○ OpenStack VMs with 4vCPUs and 4GB RAM ○ DaCapo and SpecJVM2008 benchmark suites Our Baseline Targets JVM migration; Uses PS to reduce snapshot size

slide-27
SLIDE 27

Evaluation

14

  • Evaluate ALMA’s performance compared to:

○ CRIU - Checkpoint and Restore for Linux ○ JAVMM (Hou et. al, 2015) - Extends Xen to migrate Java

  • applications. It simply collects the young generation before

migration. ○ ALMA-PS - Similar to JAVMM but based on CRIU;

  • Environment:

○ OpenStack VMs with 4vCPUs and 4GB RAM ○ DaCapo and SpecJVM2008 benchmark suites Our Baseline Targets JVM migration; Uses PS to reduce snapshot size Similar to ALMA, but using PS (as in JVMM)

slide-28
SLIDE 28

Evaluation

15

○ Application Downtime; ○ Total Migration Time; ○ Application Throughput; ○ Network Bandwidth Usage; ○ Migration-aware GC vs G1 GC (refer to paper) ○ ALMA with more resources (refer to paper)

slide-29
SLIDE 29

Evaluation

15

○ Application Downtime; ○ Total Migration Time; ○ Application Throughput; ○ Network Bandwidth Usage; ○ Migration-aware GC vs G1 GC (refer to paper) ○ ALMA with more resources (refer to paper) These metrics measure the impact of migration on application performance.

slide-30
SLIDE 30

Evaluation - Application Downtime (seconds)

16

DaCapo SPECjvm2008 The Smaller the Better! The Smaller the Better!

slide-31
SLIDE 31

Evaluation - Total Migration Time (seconds)

17

DaCapo SPECjvm2008 The Smaller the Better! The Smaller the Better!

slide-32
SLIDE 32

Evaluation - Application Throughput (normalized)

18

DaCapo SPECjvm2008 The Higher the Better! The Higher the Better!

slide-33
SLIDE 33

Evaluation - Network Bandwidth Usage (MBs)

19

DaCapo SPECjvm2008 The Smaller the Better! The Smaller the Better!

slide-34
SLIDE 34

Conclusions

20

  • ALMA offers efficient migration of Java server applications

○ by selectively avoiding garbage when it pays off

  • ALMA’s implementation is based on OpenJDK and CRIU;

○ Code is available at: github.com/rodrigo-bruno/alma

  • ALMA outperforms current solutions in:

○ Reducing application overhead ○ Reducing total migration time and downtime ○ Reducing network bandwidth usage

slide-35
SLIDE 35

Thank you for your time. Questions?

Rodrigo Bruno email: rodrigo.bruno@tecnico.ulisboa.pt webpage: www.gsd.inesc-id.pt/~rbruno alma’s github: github.com/rodrigo-bruno/alma