Job Scheduler With Dynamic Overallocation Limits
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing job scheduling systems face challenges in efficiently allocating limited resources among different classes of requestors, where each class has a distinct probability of failing to use the allocated resource and is associated with a value, leading to overallocation and potential penalties for not providing the resource.
Innovation Solution
A job scheduler that determines an overallocation limit by averaging historical probabilities and value losses across requestor classes, inflates capacity to maximize expected value, and adjusts protection levels in real-time to optimize resource allocation, while considering penalties for failure to provide resources.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the resource capacity is increased to meet all requestor demands, then the service level is improved, but the resource consumption increases and overallocation occurs
Solution Approach 1:
The system changes the capacity parameter dynamically by introducing an overallocation limit that adjusts the effective capacity based on requestor class characteristics. Different requestor classes are assigned different overallocation limits derived from their historical success probabilities, allowing the system to optimize capacity allocation without meeting every demand literally.
Solution Approach 2:
The system intentionally allocates more capacity than the strict minimum required (excessive action) up to a calculated overallocation limit, accepting that some allocations may fail but ensuring sufficient capacity for most requests. This partial overallocation strategy improves service levels while controlling resource consumption.
2Productivity
If the overallocation limit is increased to allocate more resources, then the expected value is improved, but the risk of failure to provide resources increases
Solution Approach 1:
The system uses historical data feedback to calculate overallocation limits for each requestor class based on their actual success probabilities. This feedback mechanism allows the system to learn from past performance and set appropriate allocation limits that balance expected value with failure risk for each class.
Solution Approach 2:
Different overallocation limits are applied to different requestor classes based on their specific characteristics and historical performance. High-value requestors with higher success probabilities receive higher overallocation limits, while lower-value or less reliable requestors receive more conservative limits, optimizing the balance between expected value and failure risk locally for each class.
3Reliability
If protection levels are increased to ensure resource availability, then the service reliability is improved, but the resource utilization efficiency decreases
Solution Approach 1:
The protection level is made dynamic rather than static, adjusting in real-time based on current system state, requestor class characteristics, and historical data. The system dynamically calculates optimal protection levels that ensure adequate resource availability while maximizing utilization efficiency, rather than maintaining fixed high protection levels that would waste resources.
Data Source
AI summary
Exemplary embodiments relate to the problem of allocating a finite number of units of a resource among requestors willing to offer different amounts of value for the resource. When different classes of requestors are permitted to cancel the request or fail to show up to collect the unit of the resource with different probabilities (collectively referred to as “wash”), the problem becomes difficult to solve efficiently. According to the procedures described herein, the capacity is artificially inflated to offset the impact of wash, and then protection levels are computed using the inflated capacity as if there was no wash. The capacity is then artificially inflated again based on the new protection levels, and the process is repeated until, e.g., the results converge. Using this procedure, overallocation limits and protection levels can be computed in real-time, and accordingly the resource can be allocated efficiently as new requests are received.


