1 Efficient Application Placement in a Dynamic Hosting Platform Zakaria Al-Qudah – CWRU Hussein Alzoubi – CWRU Mark Allman – ICSI Michael Rabinovich – CWRU Vincenzo 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 couldnt 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 its referenced context switching 2.On-demand page-out Full memory at the time of page-in resumption waits for page-out 3.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 (contd)

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