1

Efficient Application Placement in a Dynamic Hosting Platform

Zakaria Al-Qudah – CWRUHussein Alzoubi – CWRUMark Allman – ICSIMichael Rabinovich – CWRUVincenzo Liberatore - CWRU

2

Target Environment: Dynamic Hosting

General components App servers Local controllers Central controller Request router Measurement

modules

3

Our Problem: Enactment of resource allocation decisions

Starting applications is slow and resource-intensive Causes loss in system responsiveness Limits flexibility of resource allocation

4

Option 1: “Run Everywhere”

Run an instance of every application on every machine Send requests only to those intended to be

active

Intuition: idle application instances should not consume resources

5

Run-Everywhere Results

Conclusion: Run-everywhere is impractical

6

Option 2: Explicit Suspend/Resume

What was the problem of run-everywhere? OS couldn’t tell active applications from idle

ones due to the periodic application maintenance

Solution: explicitly convey this information to the OS Suspend idle applications with SIGSTOP Resume to activate with SIGCONT

7

Still inefficiencies: 1. On-demand page-in

OS brings a page to memory only when it’s referenced context switching

2. On-demand page-outFull memory at the time of page-in resumption waits for page-out

On-demand eviction of memory pages to disk

Piecemeal eviction process state spreads over many disjoined locations on disk

Much better!

8

Enhanced Suspend/Resume

Prefetching/prepurging = ancient swapping!

1. Bring all the process pages at once from disk to memory (prefetching)

2. Whenever an application is suspended, evict it out of memory at once (pre-purging) This keeps process state in few

contiguous places on disk

…but only for application placement

9

Performance Evaluation: Startup time

10

Performance Evaluation: Resource consumption

11

Prefetching overhead

12

Performance Evaluation: Contributing factors

13

End-to-end responsiveness: Experiment setup

14

End-to-end responsiveness - results

15

End-to-end responsiveness (cont’d)

16

Limitations of Suspend-Resume

Consequences of bad programming practices are more pronounced

Less useful for clustered applications Re-joining the cluster takes long time

(regardless of how applications are started)

Future work: Virtualization

Various technologies OS-level (e.g., OpenVZ) Hardware-level (e.g., VMware)

Vary in performance overhead and offered features (arguably!) Degree of performance/fault/security isolation Ability to run heterogeneous OSes on the same

hardware Similar suspend-resume issues might apply

Bulk prepurging Bulk prefetching

17

18

Summary

Most existing work on dynamic hosting focuses on resource allocation decisions

We focus on efficient enactment of these decisions Examined several alternatives for application placement

Deployment from scratch Run-everywhere Suspend-resume Enhanced suspend-resume

Swapping for application placement Normal paging for active tasks

Enhanced suspend-resume is significantly more efficient