resourcemanager: fix client allocation under service limits

[JmPotato]

What problem does this PR solve?

Issue Number: close #11211

A burstable group with a very large fill rate can split its finite Service Limit bucket capacity almost equally between clients, causing a busy TiDB instance to wait for RU tokens while aggregate consumption remains below the limit.

What is changed and how does it work?

Bound the client allocation budget by the positive service burst override
for burstable groups. Apply the resulting demand-based shares to bucket
capacity, newly available tokens, and the original group fill rate.

Preserve the group refill rate and the existing loan algorithm. Individual
clients receive loan shares matching their new allocations.

For a group with F = MaxInt32, a 160K service budget, and client demands of 50K/25K RU/s, capacities become 92.5K/67.5K RU. Unused budget is still shared evenly.

Check List

Tests

• Unit test
• Manual test

Manual validation used a single-host TiDB X cluster with NextGen PD/TiDB, CSE TiKV, MinIO, and two business TiDB instances in the same keyspace:

1. Set Service Limit to 24K RU/s and keep the default RU cost configuration.
2. Use 16 connections per TiDB to update disjoint rows with 16 KiB BLOBs, targeting 400/200 CPS. Warm up for 20 seconds, then alternate one active second at twice the target rate with one idle second for 90 seconds.
3. Switch only PD between baseline, fix, and baseline, keeping TiDB, CSE, and MinIO running. Hot-client cumulative RU wait was 114.50s, 0.0105s, and 181.74s respectively; aggregate net RU stayed below 24K/s in all three runs.
4. Check steady traffic and overload at 1200/600 CPS. The fixed overload run averaged 23.80K RU/s over its final 30 seconds. Its full 60-second average was 27.12K RU/s, including cached-token and transition overshoot.

The smaller payload and service budget avoid the storage bottleneck observed with 128 KiB writes in this single-host setup. This validates client allocation and service limiting, with no claim of production storage performance.

Release note

Fix unnecessary RU waits on busy TiDB instances caused by nearly equal client bucket allocation when a resource group has a large fill rate and a finite Service Limit.

Summary by CodeRabbit

• Bug Fixes

  • Improved token allocation for service-limited burstable groups.
  • Ensured burst capacity and refill rates are distributed consistently across client slots.
  • Preserved the configured total fill rate when burst capacity is capped.
  • Restored full group allocation when client slots are removed.

• Tests

  • Added coverage for unlimited, moderated, finite-refill, overridden, rate-controlled, and disabled service configurations.
  • Verified proportional capacity distribution as clients are added or removed.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: cf4e585d-31d8-4db1-a365-3eb6d6b982ba

📥 Commits

Reviewing files that changed from the base of the PR and between 867f329 and 8ec8e67.

📒 Files selected for processing (1)

• pkg/mcs/resourcemanager/server/token_buckets.go

🚧 Files skipped from review as they are similar to previous changes (1)

• pkg/mcs/resourcemanager/server/token_buckets.go

Included review availability: Your plan provides up to 4 included reviews per hour; 2 remain after this review.

---

📝 Walkthrough

Walkthrough

Token allocation now uses an explicit budget derived from the group fill rate. Service-limited burstable groups cap this budget at the overridden burst limit. Tests cover allocation, proportional capacity, and client removal across multiple configurations.

Changes

Service-limited allocation

Layer / File(s)	Summary
Capped allocation budget pkg/mcs/resourcemanager/server/token_buckets.go	balanceSlotTokens uses an allocation budget for slot fill rates, remaining capacity, burst ratios, and token assignment. Service-limited burstable groups cap the budget at the overridden burst limit while preserving the original total fill rate for slot fill-rate scaling.
Allocation behavior tests pkg/mcs/resourcemanager/server/token_buckets_test.go	TestServiceLimitedClientAllocation covers multiple group configurations, validates burst limits and fill-rate totals, checks proportional capacity assignment, and verifies full reallocation after client removal.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 8ec8e

This change caps allocation for service-limited burstable resource groups so client shares remain demand-sensitive under very large fill rates. No current merge-blocking risk is identified.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the package and the primary change: fixing client allocation under service limits.
Description check	✅ Passed	The description includes the issue reference, problem, implementation details, tests, manual validation, and release note. It matches the repository template sufficiently.
Linked Issues check	✅ Passed	The implementation directly addresses issue #11211 by bounding allocation with the finite service burst budget and making client capacity allocation demand-sensitive while preserving group refill and …
Out of Scope Changes check	✅ Passed	The code and tests are limited to service-limited client token allocation. The documented manual validation supports the stated fix and does not introduce unrelated changes.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ti-chi-bot]

@coderabbitai[bot]: adding LGTM is restricted to approvers and reviewers in OWNERS files.

Details

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ti-chi-bot]

@JmPotato: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-unit-test-next-gen-1	8ec8e67	link	true	/test pull-unit-test-next-gen-1

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.74%. Comparing base (5abc379) to head (8ec8e67).
⚠️ Report is 11 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #11213      +/-   ##
==========================================
+ Coverage   79.69%   79.74%   +0.04%     
==========================================
  Files         544      544              
  Lines       78809    78815       +6     
==========================================
+ Hits        62809    62848      +39     
+ Misses      11646    11616      -30     
+ Partials     4354     4351       -3     

Flag	Coverage Δ
unittests	79.74% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ti-chi-bot]

@YuhaoZhang00: adding LGTM is restricted to approvers and reviewers in OWNERS files.

Details

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2026-09-10 10:07:11.544006178 +0000 UTC m=+1965066.715100321: ☑️ agreed by rleungx.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: coderabbitai[bot], rleungx, YuhaoZhang00

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [rleungx]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment