1 / 39

CSE 490dp Resource Control

CSE 490dp Resource Control. Robert Grimm. Problems. How to access resources? Basic usage tracking How to measure resource consumption? Accounting How to limit resource consumption? Policy We only cover first two issues. Resource Access. Issue How to track usage? Four models

macaulay-whitehead
Download Presentation

CSE 490dp Resource Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE 490dpResource Control Robert Grimm

  2. Problems • How to access resources? • Basic usage tracking • How to measure resource consumption? • Accounting • How to limit resource consumption? • Policy • We only cover first two issues

  3. Resource Access • Issue • How to track usage? • Four models • Don’t do it • Explicit creation and deletion • Automatic reclamation of unused resources • Leases

  4. Don’t Do It • Example: NFS [Ousterhout 90] • Most operations are idempotent • No connection state • “Stateless” • Files persist • “Stateful” by definition of a file system

  5. Advantages • Crash handling • No recovery on server • No reboots on client • Simplicity • No connection handling • No recovery code

  6. Problems • Performance • No client-side caching • Consistency • Clients don’t know about others modifying same file • Semantics • Not implemented: locks • Not idempotent: mkdir

  7. Explicit Creation and Deletion • Example: Connections in Sprite FS [Ousterhout 90] • Advantages • Consistency • Server ensures only one writer per file • Performance • Client-side caching • No synchronous writes to server • Files may be overwritten / deletedbefore they get sent to server

  8. Problems • Complexity • More to do on server • Recovery • How to restore connections after failure? • Performance • Explicit open and close operations • Space overheads • Per-connection state

  9. Pervasive Paradigm • new / delete • C, C++ • create / delete • Files • Tuples in T Spaces, one.world • run / kill • Applications, servers

  10. Automatic Reclamation • Garbage collection • Basic idea • Keep track of used resources • Automatically reclaim unused resourcesin background • Examples • Locally for Java • Distributed for Java RMI

  11. Discussion • Advantage • No need to worry about deletion • Problem • Complete and reliable usage information is hard to come by • Network connections and nodes fail • May depend on human factors • Hard to automate

  12. Discussion • Can we automate creation and deletion? • Cluster-based service • Automatically run and kill serviceson individual nodes

  13. Leases • Basic idea • Limit resource access by time-out • Reclaim resource after time-out expires • Operations • Acquire (open) • Renew • Cancel (close)

  14. Examples • Remote resources • Java RMI • Jini’s remote events, transactions • File cache • V [Gray & Cheriton 89] • Storage • JavaSpaces • Resource access in general • one.world

  15. Problem • A resource can always vanish • Lease renewal is delayed • E.g., message may be delayed, is lost • Lease expires

  16. Tracking Usage • Don’t do it • Explicit creation and deletion • Garbage collection • Automate deletion based on usage • Leases • Automate deletion based on time-out

  17. Resources • Transient • Objects, connections • Services • Applications • User data • Files, tuples

  18. Summary

  19. Break

  20. Resource Accounting • Problem • Traditionally, process represents • Protection domain • Resource principal • But, modern servers don’t follow this model • [Banga et al., 99]

  21. HTTP Server Implementations • One process per connection • Event-based server • Multi-threaded server

  22. One Process Per Connection

  23. Event-Based Server

  24. Multi-Threaded Server

  25. Scheduling Entities and Activities • Classical application • Single process • Mostly user space • Modern applications • Considerable kernel processing • Multiple processes • Multiple threads

  26. Classical Application

  27. Considerable Kernel Processing

  28. Multiple Processes

  29. Multiple Threads

  30. How to Account for Resources? • Introduce new abstraction • Resource container • Tracks usage information • CPU time • Memory • Networking bandwidth • … • Orthogonal to scheduling entities • Threads, processes have resource binding

  31. Scheduler Binding • Problem • How to schedule threads that are bound to several resource containers? • E.g., event-based server • Solution • Scheduler binding • Set of all resource containers

  32. Operations • Create • Set parent • Hierarchy of containers • Release • Reference counted • Share • Access attributes • Access usage information

  33. Operations • Bind thread to a container • Reset scheduler binding • Bind socket, file to a container

  34. Usage • One resource container per logical job • Create new container when accepting connection • Change thread’s container as necessary • Example policy • Different classes of clients, depending on source IP address • Low priority • High priority

  35. Performance • Growing number of low priority clients

  36. Performance • Growing number of concurrent CGI requests

  37. Performance • Growing SYN-flood rate

  38. Summary • Resource accounting is orthogonal to • Protection • Scheduling • Need explicit abstraction • Resource containers

  39. Issues • How to express and enforce policies? • How to make resource containers scale across the network?

More Related