Resource Containers: A New Facility for Resource Management in Server Systems
One-line Summary
A resource container is an operating systems abstraction that separates the notion of a protection domain from a resource principal. It allows for fine-grained resource management.
Paper Structure Outline
Introduction
Typical models for high-performance servers
Shortcomings of current resource management models
The distinction between scheduling entities and activities
Integrating network processing with resource management
Consequences of misidentified resource principals
A new model for resource management
Resource containers
Containers, processes, and threads
Resource containers and CPU scheduling
Other resources
The resource container hierarchy
Operations on resource containers
Kernel execution model
The use of resource containers
Performance
Prototype implementation
Experimental environment
Baseline throughput
Costs of new primitives
Prioritized handling of clients
Controlling resource usage of CGI processing
Immunity against SYN-flooding
Isolation of virtual servers
Related Work
Conclusion
Background & Motivation
In resource management, current systems do not separate the notion of "protection domain" (where the accounting of the tasks is done) and "resource principal" (where actual work gets performed). Processes and threads are both resource principals as well as protection domains. Also, an application does not have control over how much resources the kernel consumes on behalf of the application. In this work, the two notions are separated by the new operating systems abstraction, resource containers.
Existing models include (1) process-per connection, (2) single-process event-driven connection, and (3) multi-threaded server.
The authors then presented some analyses in section 3 to analyze the shortcomings of the current models.
Design and Implementation
Instead of binding threads of application space processes, threads bind to different resource containers (RC), a new abstraction that extends into the kernel and thus has knowledge of which os entities are doing work for which application-level clients. Resource containers logically contain all types of resources (CPU time, sockets, control blocks, network buffers) being used by an application. Containers are also attached with attributes to limit resources (CPU availability), provide scheduling priorities, and network QoS values.
To use resource containers with multiple threads:
Threads are assigned to RCs for each new connection as soon as identified from request info
Kernel processing is charged to this container
We can have different RCs for different QoS policies
The OS scheduler appropriately schedules threads by priority/resource usage. If the thread consumes more than its fair share of resources, its scheduling priority decays.
To use resource containers with events:
Threads switch to the desired resource containers as they handle new events
No need for scheduling by OS
The associated container will be charged for the processing the thread performs for them
Resource containers just track accounting
Applications use the information to determine the order to handle events
Evaluation
Resource containers allow explicit and fine-grained control over resource consumption at both user-level and kernel-level. They can provide accurate resource accounting, enabling web servers to provide differentiated QoS.
New Vocabulary
Resource principals: Entities for which separate resource allocation and accounting are done
Protection domain: Entities that need to be isolated from each other
QoS: Quality of Service
Links
Last updated
Was this helpful?
