resource_control: support calibrate resource

[glorv]

What problem does this PR solve?

Issue Number: ref #38825

Problem Summary:

What is changed and how it works?

This PR add a new statement calibrate resource to estimate the total Request-Units(RU) of the current cluster.
Because the total ru usage is related to workload resource consuming, so the maximum RU can be different with different workload. Thus, the maximum RU estimated by this PR is based on a given workload -- TPC-C, and we may support other workload(e.g. sysbench) in the future.

In general, the bottle of a cluster can be one of TiDB CPU, TiKV CPU, TiKV IO Bandwidth. Currently, we can get the exact IO bandwidth and for most workload, io is unlikely to be the bottleneck. So here, we only consider TiDB CPU or TiKV CPU as bottleneck.

For a specified workload, the resource consuming is linear co-related with each other. So this PR use pre-benchmarked data of each resource dimension to calculate the ru cost per 1 tikv cpu. So if tikv cpu is the bottleneck, then Max RU = max_ru_per_1_kv_cpu * Total_TiKV_CPU; if tidb cpu is the bottleneck, then we just decrease the total kv cpu with a certain portaion.

The PR calculate the RU cost of different resource dimension separated so we can support calculate total ru with custom ru config and the expected RU capacity can reflect the RU config change.

The current SQL UI is as follows(We may add more information in the future version):

mysql> calibrate resource;
+-------+
| QUOTA |
+-------+
| 68569 |
+-------+
1 row in set (0.18 sec)

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

Support estimate cluster total request unit with `calibrate resource`

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• JmPotato
• nolouch

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

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

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[ti-chi-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[glorv]

@nolouch @BornChanger PTAL

[glorv]

/test all

[glorv]

/retest

[nolouch]

Overall LGTM.

[nolouch]

Does it means 1 core can provide 1750 request in here? maybe add more comments.

[glorv]

Yes. It is based on benchmark result. I added comment on the baseResourceCost struct

[JmPotato]

What about using a const or defined type?

[glorv]

done

[Connor1996]

please clean it

[tiancaiamao]

The result could be inaccurate.
It has many hypothesis, like the bottlenect is TiDB | TiKV CPU, like the workload assumption, like the performance on different hardware...

[glorv]

The result could be inaccurate. It has many hypothesis, like the bottlenect is TiDB | TiKV CPU, like the workload assumption, like the performance on different hardware...

Yes. This is the restriction of the current implementation. We plan to expand this command to support estimating the RU capacity based on user's workload dynamically, this should be more useful for the user.

[glorv]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: a6d48fb