180 likes | 310 Views
Efficient Application Placement in a Dynamic Hosting Platform. Zakaria Al-Qudah – CWRU Hussein Alzoubi – CWRU Mark Allman – ICSI Michael Rabinovich – CWRU Vincenzo Liberatore - CWRU. Target Environment: Dynamic Hosting. General components App servers Local controllers Central controller
E N D
Efficient Application Placement in a Dynamic Hosting Platform Zakaria Al-Qudah – CWRU Hussein Alzoubi – CWRU Mark Allman – ICSI Michael Rabinovich – CWRU Vincenzo Liberatore - CWRU
Target Environment: Dynamic Hosting • General components • App servers • Local controllers • Central controller • Request router • Measurement modules
Our Problem: Enactment of resource allocation decisions • Starting applications is slow and resource-intensive • Causes loss in system responsiveness • Limits flexibility of resource allocation
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
Run-Everywhere Results • Conclusion: Run-everywhere is impractical
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
Still inefficiencies: Much better! • On-demand page-in OS brings a page to memory only when it’s referenced context switching • On-demand page-out Full 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
Enhanced Suspend/Resume • Bring all the process pages at once from disk to memory (prefetching) • Whenever an application is suspended, evict it out of memory at once (pre-purging) • This keeps process state in few contiguous places on disk Prefetching/prepurging = ancient swapping! …but only for application placement
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
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