grpc: set MaxConcurrentStreams to avoid sudden traffic spikes that lead to PD OOM

[okJiang]

What problem does this PR solve?

Issue Number: Close #8882, ref #4480

What is changed and how does it work?

Added MaxConcurrentStreams to limit the request concurrency. This is a self-protection mechanism of PD. Once the number of concurrent requests reaches the limit, gRPC will wait for the ongoing requests to finish and allocate resources to the waiting requests. Therefore, in this situation, the request time may slow down, but it will provide better robustness.

PS: This parameter cannot be modified during runtime, so we cannot support changing it by pd-ctl. If you think it should be configurable, please comment.

Check List

Tests

• Unit test
• Integration test

Release note

None.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign benmeadowcroft for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• server/config/OWNERS

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

[ti-chi-bot]

@okJiang: 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-integration-realcluster-test	f9a16f4	link	true	/test pull-integration-realcluster-test

Full PR test history. Your PR dashboard.

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

Attention: Patch coverage is 57.14286% with 3 lines in your changes missing coverage. Please review.

Project coverage is 76.30%. Comparing base (41919ad) to head (f9a16f4).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8977      +/-   ##
==========================================
- Coverage   76.31%   76.30%   -0.02%     
==========================================
  Files         465      465              
  Lines       70547    70553       +6     
==========================================
- Hits        53839    53834       -5     
- Misses      13361    13370       +9     
- Partials     3347     3349       +2     

Flag	Coverage Δ
unittests	76.30% <57.14%> (-0.02%)	⬇️

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

[rleungx]

Is there any tests to support the conclusion?

[okJiang]

This conclusion comes from a practical case where the cluster contains millions of regions. And its requests are ScanRegions mainly.

[rleungx]

CMIIW, it only limits the concurrency for one connection, not total concurrency on the server side.

[okJiang]

In simple terms, should we consider this sudden surge in traffic as an anomaly? If so, I think we can set this parameter to protect PD. Do you know in what normal circumstances PD would experience such high traffic? For example, 16GB PD and 160k requests.

[okJiang]

https://github.com/etcd-io/etcd/blob/fce823ac2830033270f8fe03fa1b56e62bf882b8/server/embed/config.go#L230-L232

// MaxConcurrentStreams specifies the maximum number of concurrent
// streams that each client can open at a time.

If users make massive requests using multiple clients, we have no way to limit it...