Conversation
Signed-off-by: rishabh_mittal <rishabh.mittal@airbnb.com>
| @@ -0,0 +1,273 @@ | |||
| # Design Doc: Fair Scheduling Based on Historical RU Consumption | |||
There was a problem hiding this comment.
Seems the RFC is still tuning the priority of requests and impact the schedule of the read pool, I don't see the throttling mechanism.
Essentially I think we should have a instance level (read pool) self protection throttling mechanism to prevent any requests from any tenants/resource group making the instance overloaded. tikv/tikv#19319 has a similar goal?
There was a problem hiding this comment.
It is not throttled via rate limiting. Instead, throttling happens through queue eviction when the queue is full or slow scheduling. The goal is to protect sustained traffic by deprioritizing the traffic that is causing the overload.
tikv/tikv#19319 is penalizing the tenants based on their rate limit.
There was a problem hiding this comment.
consider this scenario
Steady state:
- Tenant_1: consuming 10000 RU/s (sustained workload)
- Tenant_2: consuming 20000 RU/s (sustained workload)
- System: stable
Sudden spike:
- Tenant_3: traffic suddenly increases to 5000, overloading the system
Expected:
- Throttle Tenant_3 (the new traffic causing overload)
- Protect Tenant_1 and Tenant_2 (sustained traffic)
created RFC for resource group isolation.