diff --git a/doc/administration/gitaly/concurrency_limiting.md b/doc/administration/gitaly/concurrency_limiting.md
new file mode 100644
index 0000000000000000000000000000000000000000..42194d727cc7b5129bdab0cd04d6cc46b5ed51ac
--- /dev/null
+++ b/doc/administration/gitaly/concurrency_limiting.md
@@ -0,0 +1,244 @@
+---
+stage: Systems
+group: Gitaly
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Concurrency limiting
+
+To avoid overwhelming the servers running Gitaly, you can limit concurrency of:
+
+- RPCs.
+- Pack objects.
+
+These limits can be fixed, or set as adaptive.
+
+WARNING:
+Enabling limits on your environment should be done with caution and only
+in select circumstances, such as to protect against unexpected traffic.
+When reached, limits _do_ result in disconnects that negatively impact users.
+For consistent and stable performance, you should first explore other options such as
+adjusting node specifications, and [reviewing large repositories](../../user/project/repository/managing_large_repositories.md) or workloads.
+
+## Limit RPC concurrency
+
+When cloning or pulling repositories, various RPCs run in the background. In particular, the Git pack RPCs:
+
+- `SSHUploadPackWithSidechannel` (for Git SSH).
+- `PostUploadPackWithSidechannel` (for Git HTTP).
+
+These RPCs can consume a large amount of resources, which can have a significant impact in situations such as:
+
+- Unexpectedly high traffic.
+- Running against [large repositories](../../user/project/repository/managing_large_repositories.md) that don't follow best practices.
+
+You can limit these processes from overwhelming your Gitaly server in these scenarios using the concurrency limits in the Gitaly configuration file. For
+example:
+
+```ruby
+# in /etc/gitlab/gitlab.rb
+gitaly['configuration'] = {
+ # ...
+ concurrency: [
+ {
+ rpc: '/gitaly.SmartHTTPService/PostUploadPackWithSidechannel',
+ max_per_repo: 20,
+ max_queue_wait: '1s',
+ max_queue_size: 10,
+ },
+ {
+ rpc: '/gitaly.SSHService/SSHUploadPackWithSidechannel',
+ max_per_repo: 20,
+ max_queue_wait: '1s',
+ max_queue_size: 10,
+ },
+ ],
+}
+```
+
+- `rpc` is the name of the RPC to set a concurrency limit for per repository.
+- `max_per_repo` is the maximum number of in-flight RPC calls for the given RPC per repository.
+- `max_queue_wait` is the maximum amount of time a request can wait in the concurrency queue to
+ be picked up by Gitaly.
+- `max_queue_size` is the maximum size the concurrency queue (per RPC method) can grow to before requests are rejected by
+ Gitaly.
+
+This limits the number of in-flight RPC calls for the given RPCs. The limit is applied per
+repository. In the example above:
+
+- Each repository served by the Gitaly server can have at most 20 simultaneous `PostUploadPackWithSidechannel` and
+ `SSHUploadPackWithSidechannel` RPC calls in flight.
+- If another request comes in for a repository that has used up its 20 slots, that request gets
+ queued.
+- If a request waits in the queue for more than 1 second, it is rejected with an error.
+- If the queue grows beyond 10, subsequent requests are rejected with an error.
+
+NOTE:
+When these limits are reached, users are disconnected.
+
+You can observe the behavior of this queue using the Gitaly logs and Prometheus. For more
+information, see the [relevant documentation](monitoring.md#monitor-gitaly-concurrency-limiting).
+
+## Limit pack-objects concurrency
+
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/7891) in GitLab 15.11 [with a flag](../../administration/feature_flags.md) named `gitaly_pack_objects_limiting_remote_ip`. Disabled by default.
+> - [Generally available](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/5772) in GitLab 16.0. Feature flag `gitaly_pack_objects_limiting_remote_ip` removed.
+
+Gitaly triggers `git-pack-objects` processes when handling both SSH and HTTPS traffic to clone or pull repositories. These processes generate a `pack-file` and can
+consume a significant amount of resources, especially in situations such as unexpectedly high traffic or concurrent pulls from a large repository. On GitLab.com, we also
+observe problems with clients that have slow internet connections.
+
+You can limit these processes from overwhelming your Gitaly server by setting pack-objects concurrency limits in the Gitaly configuration file. This setting limits the
+number of in-flight pack-object processes per remote IP address.
+
+WARNING:
+Only enable these limits on your environment with caution and only in select circumstances, such as to protect against unexpected traffic. When reached, these limits
+disconnect users. For consistent and stable performance, you should first explore other options such as adjusting node specifications, and
+[reviewing large repositories](../../user/project/repository/managing_large_repositories.md) or workloads.
+
+Example configuration:
+
+```ruby
+# in /etc/gitlab/gitlab.rb
+gitaly['pack_objects_limiting'] = {
+ 'max_concurrency' => 15,
+ 'max_queue_length' => 200,
+ 'max_queue_wait' => '60s',
+}
+```
+
+- `max_concurrency` is the maximum number of in-flight pack-object processes per key.
+- `max_queue_length` is the maximum size the concurrency queue (per key) can grow to before requests are rejected by Gitaly.
+- `max_queue_wait` is the maximum amount of time a request can wait in the concurrency queue to be picked up by Gitaly.
+
+In the example above:
+
+- Each remote IP can have at most 15 simultaneous pack-object processes in flight on a Gitaly node.
+- If another request comes in from an IP that has used up its 15 slots, that request gets queued.
+- If a request waits in the queue for more than 1 minute, it is rejected with an error.
+- If the queue grows beyond 200, subsequent requests are rejected with an error.
+
+When the pack-object cache is enabled, pack-objects limiting kicks in only if the cache is missed. For more, see [Pack-objects cache](configure_gitaly.md#pack-objects-cache).
+
+You can observe the behavior of this queue using Gitaly logs and Prometheus. For more information, see
+[Monitor Gitaly pack-objects concurrency limiting](monitoring.md#monitor-gitaly-pack-objects-concurrency-limiting).
+
+## Adaptive concurrency limiting
+
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10734) in GitLab 16.6.
+
+Gitaly supports two concurrency limits:
+
+- An [RPC concurrency limit](#limit-rpc-concurrency), which allow you to configure a maximum number of simultaneous in-flight requests for each
+ Gitaly RPC. The limit is scoped by RPC and repository.
+- A [Pack-objects concurrency limit](#limit-pack-objects-concurrency), which restricts the number of concurrent Git data transfer request by IP.
+
+If this limit is exceeded, either:
+
+- The request is put in a queue.
+- The request is rejected if the queue is full or if the request remains in the queue for too long.
+
+Both of these concurrency limits can be configured statically. Though static limits can yield good protection results, they have some drawbacks:
+
+- Static limits are not good for all usage patterns. There is no one-size-fits-all value. If the limit is too low, big repositories are
+ negatively impacted. If the limit is too high, the protection is essentially lost.
+- It's tedious to maintain a sane value for the concurrency limit, especially when the workload of each repository changes over time.
+- A request can be rejected even though the server is idle because the rate doesn't factor in the load on the server.
+
+You can overcome all of these drawbacks and keep the benefits of concurrency limiting by configuring adaptive concurrency limits. Adaptive
+concurrency limits are optional and build on the two concurrency limiting types. It uses Additive Increase/Multiplicative Decrease (AIMD)
+algorithm. Each adaptive limit:
+
+- Gradually increases up to a certain upper limit during typical process functioning.
+- Quickly decreases when the host machine has a resource problem.
+
+This mechanism provides some headroom for the machine to "breathe" and speeds up current inflight requests.
+
+
+
+The adaptive limiter calibrates the limits every 30 seconds and:
+
+- Increases the limits by one until reaching the upper limit.
+- Decreases the limits by half when the top-level cgroup has either memory usage that exceeds 90%, excluding highly-evictable page caches,
+ or CPU throttled for 50% or more of the observation time.
+
+Otherwise, the limits increase by one until reaching the upper bound. For more information about technical implementation
+of this system, please refer to [this blueprint](../../architecture/blueprints/gitaly_adaptive_concurrency_limit/index.md).
+
+Adaptive limiting is enabled for each RPC or pack-objects cache individually. However, limits are calibrated at the same time.
+
+### Enable adaptiveness for RPC concurrency
+
+Prerequisites:
+
+- Because adaptive limiting depends on [control groups](configure_gitaly.md#control-groups), control groups must be enabled before using adaptive limiting.
+
+The following is an example to configure an adaptive limit for RPC concurrency:
+
+```ruby
+# in /etc/gitlab/gitlab.rb
+gitaly['configuration'] = {
+ # ...
+ concurrency: [
+ {
+ rpc: '/gitaly.SmartHTTPService/PostUploadPackWithSidechannel',
+ max_queue_wait: '1s',
+ max_queue_size: 10,
+ adaptive: true,
+ min_limit: 10,
+ initial_limit: 20,
+ max_limit: 40
+ },
+ {
+ rpc: '/gitaly.SSHService/SSHUploadPackWithSidechannel',
+ max_queue_wait: '10s',
+ max_queue_size: 20,
+ adaptive: true,
+ min_limit: 10,
+ initial_limit: 50,
+ max_limit: 100
+ },
+ ],
+}
+```
+
+In this example:
+
+- `adaptive` sets whether the adaptiveness is enabled. If set, the `max_per_repo` value is ignored in favor of the following configuration.
+- `initial_limit` is the per-repository concurrency limit to use when Gitaly starts.
+- `max_limit` is the minimum per-repository concurrency limit of the configured RPC. Gitaly increases the current limit
+ until it reaches this number.
+- `min_limit` is the is the minimum per-repository concurrency limit of the configured RPC. When the host machine has a resource problem,
+ Gitaly quickly reduces the limit until reaching this value.
+
+For more information, see [RPC concurrency](#limit-rpc-concurrency).
+
+### Enable adaptiveness for pack-objects concurrency
+
+Prerequisites:
+
+- Because adaptive limiting depends on [control groups](configure_gitaly.md#control-groups), control groups must be enabled before using adaptive limiting.
+
+The following is an example to configure an adaptive limit for pack-objects concurrency:
+
+```ruby
+# in /etc/gitlab/gitlab.rb
+gitaly['pack_objects_limiting'] = {
+ 'max_queue_length' => 200,
+ 'max_queue_wait' => '60s',
+ 'adaptive' => true,
+ 'min_limit' => 10,
+ 'initial_limit' => 20,
+ 'max_limit' => 40
+}
+```
+
+In this example:
+
+- `adaptive` sets whether the adaptiveness is enabled. If set, the value of `max_concurrency` is ignored in favor of the following configuration.
+- `initial_limit` is the per-IP concurrency limit to use when Gitaly starts.
+- `max_limit` is the minimum per-IP concurrency limit for pack-objects. Gitaly increases the current limit until it reaches this number.
+- `min_limit` is the is the minimum per-IP concurrency limit for pack-objects. When the host machine has a resources problem, Gitaly quickly
+ reduces the limit until it reaches this value.
+
+For more information, see [pack-objects concurrency](#limit-pack-objects-concurrency).
diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index 19403164abd4db8fced06fadb6a8110896dee931..891416a7debb28dd667a94575abfcfbd42054e33 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -26,8 +26,8 @@ Configure Gitaly in one of two ways:
The following configuration options are also available:
- Enabling [TLS support](tls_support.md).
-- Limiting [RPC concurrency](#limit-rpc-concurrency).
-- Limiting [pack-objects concurrency](#limit-pack-objects-concurrency).
+- Limiting [RPC concurrency](concurrency_limiting.md#limit-rpc-concurrency).
+- Limiting [pack-objects concurrency](concurrency_limiting.md#limit-pack-objects-concurrency).
## About the Gitaly token
@@ -567,236 +567,6 @@ Disable Gitaly on a GitLab server in one of two ways:
::EndTabs
-## Limit RPC concurrency
-
-WARNING:
-Enabling limits on your environment should be done with caution and only
-in select circumstances, such as to protect against unexpected traffic.
-When reached, limits _do_ result in disconnects that negatively impact users.
-For consistent and stable performance, you should first explore other options such as
-adjusting node specifications, and [reviewing large repositories](../../user/project/repository/managing_large_repositories.md) or workloads.
-
-When cloning or pulling repositories, various RPCs run in the background. In particular, the Git pack RPCs:
-
-- `SSHUploadPackWithSidechannel` (for Git SSH).
-- `PostUploadPackWithSidechannel` (for Git HTTP).
-
-These RPCs can consume a large amount of resources, which can have a significant impact in situations such as:
-
-- Unexpectedly high traffic.
-- Running against [large repositories](../../user/project/repository/managing_large_repositories.md) that don't follow best practices.
-
-You can limit these processes from overwhelming your Gitaly server in these scenarios using the concurrency limits in the Gitaly configuration file. For
-example:
-
-```ruby
-# in /etc/gitlab/gitlab.rb
-gitaly['configuration'] = {
- # ...
- concurrency: [
- {
- rpc: '/gitaly.SmartHTTPService/PostUploadPackWithSidechannel',
- max_per_repo: 20,
- max_queue_wait: '1s',
- max_queue_size: 10,
- },
- {
- rpc: '/gitaly.SSHService/SSHUploadPackWithSidechannel',
- max_per_repo: 20,
- max_queue_wait: '1s',
- max_queue_size: 10,
- },
- ],
-}
-```
-
-- `rpc` is the name of the RPC to set a concurrency limit for per repository.
-- `max_per_repo` is the maximum number of in-flight RPC calls for the given RPC per repository.
-- `max_queue_wait` is the maximum amount of time a request can wait in the concurrency queue to
- be picked up by Gitaly.
-- `max_queue_size` is the maximum size the concurrency queue (per RPC method) can grow to before requests are rejected by
- Gitaly.
-
-This limits the number of in-flight RPC calls for the given RPCs. The limit is applied per
-repository. In the example above:
-
-- Each repository served by the Gitaly server can have at most 20 simultaneous `PostUploadPackWithSidechannel` and
- `SSHUploadPackWithSidechannel` RPC calls in flight.
-- If another request comes in for a repository that has used up its 20 slots, that request gets
- queued.
-- If a request waits in the queue for more than 1 second, it is rejected with an error.
-- If the queue grows beyond 10, subsequent requests are rejected with an error.
-
-NOTE:
-When these limits are reached, users are disconnected.
-
-You can observe the behavior of this queue using the Gitaly logs and Prometheus. For more
-information, see the [relevant documentation](monitoring.md#monitor-gitaly-concurrency-limiting).
-
-## Limit pack-objects concurrency
-
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/7891) in GitLab 15.11 [with a flag](../../administration/feature_flags.md) named `gitaly_pack_objects_limiting_remote_ip`. Disabled by default.
-> - [Generally available](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/5772) in GitLab 16.0. Feature flag `gitaly_pack_objects_limiting_remote_ip` removed.
-
-Gitaly triggers `git-pack-objects` processes when handling both SSH and HTTPS traffic to clone or pull repositories. These processes generate a `pack-file` and can
-consume a significant amount of resources, especially in situations such as unexpectedly high traffic or concurrent pulls from a large repository. On GitLab.com, we also
-observe problems with clients that have slow internet connections.
-
-You can limit these processes from overwhelming your Gitaly server by setting pack-objects concurrency limits in the Gitaly configuration file. This setting limits the
-number of in-flight pack-object processes per remote IP address.
-
-WARNING:
-Only enable these limits on your environment with caution and only in select circumstances, such as to protect against unexpected traffic. When reached, these limits
-disconnect users. For consistent and stable performance, you should first explore other options such as adjusting node specifications, and
-[reviewing large repositories](../../user/project/repository/managing_large_repositories.md) or workloads.
-
-Example configuration:
-
-```ruby
-# in /etc/gitlab/gitlab.rb
-gitaly['pack_objects_limiting'] = {
- 'max_concurrency' => 15,
- 'max_queue_length' => 200,
- 'max_queue_wait' => '60s',
-}
-```
-
-- `max_concurrency` is the maximum number of in-flight pack-object processes per key.
-- `max_queue_length` is the maximum size the concurrency queue (per key) can grow to before requests are rejected by Gitaly.
-- `max_queue_wait` is the maximum amount of time a request can wait in the concurrency queue to be picked up by Gitaly.
-
-In the example above:
-
-- Each remote IP can have at most 15 simultaneous pack-object processes in flight on a Gitaly node.
-- If another request comes in from an IP that has used up its 15 slots, that request gets queued.
-- If a request waits in the queue for more than 1 minute, it is rejected with an error.
-- If the queue grows beyond 200, subsequent requests are rejected with an error.
-
-When the pack-object cache is enabled, pack-objects limiting kicks in only if the cache is missed. For more, see [Pack-objects cache](#pack-objects-cache).
-
-You can observe the behavior of this queue using Gitaly logs and Prometheus. For more information, see
-[Monitor Gitaly pack-objects concurrency limiting](monitoring.md#monitor-gitaly-pack-objects-concurrency-limiting).
-
-## Adaptive concurrency limiting
-
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10734) in GitLab 16.6.
-
-Gitaly supports two concurrency limits:
-
-- An [RPC concurrency limit](#limit-rpc-concurrency), which allow you to configure a maximum number of simultaneous in-flight requests for each
- Gitaly RPC. The limit is scoped by RPC and repository.
-- A [Pack-objects concurrency limit](#limit-pack-objects-concurrency), which restricts the number of concurrent Git data transfer request by IP.
-
-If this limit is exceeded, either:
-
-- The request is put in a queue.
-- The request is rejected if the queue is full or if the request remains in the queue for too long.
-
-Both of these concurrency limits can be configured statically. Though static limits can yield good protection results, they have some drawbacks:
-
-- Static limits are not good for all usage patterns. There is no one-size-fits-all value. If the limit is too low, big repositories are
- negatively impacted. If the limit is too high, the protection is essentially lost.
-- It's tedious to maintain a sane value for the concurrency limit, especially when the workload of each repository changes over time.
-- A request can be rejected even though the server is idle because the rate doesn't factor in the load on the server.
-
-You can overcome all of these drawbacks and keep the benefits of concurrency limiting by configuring adaptive concurrency limits. Adaptive
-concurrency limits are optional and build on the two concurrency limiting types. It uses Additive Increase/Multiplicative Decrease (AIMD)
-algorithm. Each adaptive limit:
-
-- Gradually increases up to a certain upper limit during typical process functioning.
-- Quickly decreases when the host machine has a resource problem.
-
-This mechanism provides some headroom for the machine to "breathe" and speeds up current inflight requests.
-
-
-
-The adaptive limiter calibrates the limits every 30 seconds and:
-
-- Increases the limits by one until reaching the upper limit.
-- Decreases the limits by half when the top-level cgroup has either memory usage that exceeds 90%, excluding highly-evictable page caches,
- or CPU throttled for 50% or more of the observation time.
-
-Otherwise, the limits increase by one until reaching the upper bound. For more information about technical implementation
-of this system, please refer to [this blueprint](../../architecture/blueprints/gitaly_adaptive_concurrency_limit/index.md).
-
-Adaptive limiting is enabled for each RPC or pack-objects cache individually. However, limits are calibrated at the same time.
-
-### Enable adaptiveness for RPC concurrency
-
-Prerequisites:
-
-- Because adaptive limiting depends on [control groups](#control-groups), control groups must be enabled before using adaptive limiting.
-
-The following is an example to configure an adaptive limit for RPC concurrency:
-
-```ruby
-# in /etc/gitlab/gitlab.rb
-gitaly['configuration'] = {
- # ...
- concurrency: [
- {
- rpc: '/gitaly.SmartHTTPService/PostUploadPackWithSidechannel',
- max_queue_wait: '1s',
- max_queue_size: 10,
- adaptive: true,
- min_limit: 10,
- initial_limit: 20,
- max_limit: 40
- },
- {
- rpc: '/gitaly.SSHService/SSHUploadPackWithSidechannel',
- max_queue_wait: '10s',
- max_queue_size: 20,
- adaptive: true,
- min_limit: 10,
- initial_limit: 50,
- max_limit: 100
- },
- ],
-}
-```
-
-In this example:
-
-- `adaptive` sets whether the adaptiveness is enabled. If set, the `max_per_repo` value is ignored in favor of the following configuration.
-- `initial_limit` is the per-repository concurrency limit to use when Gitaly starts.
-- `max_limit` is the minimum per-repository concurrency limit of the configured RPC. Gitaly increases the current limit
- until it reaches this number.
-- `min_limit` is the is the minimum per-repository concurrency limit of the configured RPC. When the host machine has a resource problem,
- Gitaly quickly reduces the limit until reaching this value.
-
-For more information, see [RPC concurrency](#limit-rpc-concurrency).
-
-### Enable adaptiveness for pack-objects concurrency
-
-Prerequisites:
-
-- Because adaptive limiting depends on [control groups](#control-groups), control groups must be enabled before using adaptive limiting.
-
-The following is an example to configure an adaptive limit for pack-objects concurrency:
-
-```ruby
-# in /etc/gitlab/gitlab.rb
-gitaly['pack_objects_limiting'] = {
- 'max_queue_length' => 200,
- 'max_queue_wait' => '60s',
- 'adaptive' => true,
- 'min_limit' => 10,
- 'initial_limit' => 20,
- 'max_limit' => 40
-}
-```
-
-In this example:
-
-- `adaptive` sets whether the adaptiveness is enabled. If set, the value of `max_concurrency` is ignored in favor of the following configuration.
-- `initial_limit` is the per-IP concurrency limit to use when Gitaly starts.
-- `max_limit` is the minimum per-IP concurrency limit for pack-objects. Gitaly increases the current limit until it reaches this number.
-- `min_limit` is the is the minimum per-IP concurrency limit for pack-objects. When the host machine has a resources problem, Gitaly quickly
- reduces the limit until it reaches this value.
-
-For more information, see [pack-objects concurrency](#limit-pack-objects-concurrency).
-
## Control groups
WARNING:
diff --git a/doc/administration/gitaly/monitoring.md b/doc/administration/gitaly/monitoring.md
index e315ae2f27e4320a42a3096af47b48819dede731..0527c846b2dffafa05288e18078e1b7fb412e787 100644
--- a/doc/administration/gitaly/monitoring.md
+++ b/doc/administration/gitaly/monitoring.md
@@ -31,7 +31,7 @@ of requests dropped due to request limiting. The `reason` label indicates why a
## Monitor Gitaly concurrency limiting
-You can observe specific behavior of [concurrency-queued requests](configure_gitaly.md#limit-rpc-concurrency) using Gitaly logs and Prometheus.
+You can observe specific behavior of [concurrency-queued requests](concurrency_limiting.md#limit-rpc-concurrency) using Gitaly logs and Prometheus.
In the [Gitaly logs](../logs/index.md#gitaly-logs), you can identify logs related to the pack-objects concurrency limiting with entries such as:
@@ -62,7 +62,7 @@ In Prometheus, look for the following metrics:
## Monitor Gitaly pack-objects concurrency limiting
-You can observe specific behavior of [pack-objects limiting](configure_gitaly.md#limit-pack-objects-concurrency) using Gitaly logs and Prometheus.
+You can observe specific behavior of [pack-objects limiting](concurrency_limiting.md#limit-pack-objects-concurrency) using Gitaly logs and Prometheus.
In the [Gitaly logs](../logs/index.md#gitaly-logs), you can identify logs related to the pack-objects concurrency limiting with entries such as:
@@ -94,7 +94,7 @@ In Prometheus, look for the following metrics:
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10734) in GitLab 16.6.
-You can observe specific behavior of [adaptive concurrency limiting](configure_gitaly.md#adaptive-concurrency-limiting) using Gitaly logs and Prometheus.
+You can observe specific behavior of [adaptive concurrency limiting](concurrency_limiting.md#adaptive-concurrency-limiting) using Gitaly logs and Prometheus.
In the [Gitaly logs](../logs/index.md#gitaly-logs), you can identify logs related to the adaptive concurrency limiting when the current limits are adjusted.
You can filter the content of the logs (`msg`) for "Multiplicative decrease" and "Additive increase" messages.
diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md
index 402ecfeec7bd7bf7b1c9cd965d2e06cfa7380292..d8b2b27a9694aae5325c9c1787674b7a51ef036d 100644
--- a/doc/administration/instance_limits.md
+++ b/doc/administration/instance_limits.md
@@ -202,7 +202,7 @@ Read more about [pipeline creation rate limits](settings/rate_limit_on_pipelines
Clone traffic can put a large strain on your Gitaly service. To prevent such workloads from overwhelming your Gitaly server, you can set concurrency limits in the Gitaly configuration file.
-Read more about [Gitaly concurrency limits](gitaly/configure_gitaly.md#limit-rpc-concurrency).
+Read more about [Gitaly concurrency limits](gitaly/concurrency_limiting.md#limit-rpc-concurrency).
- **Default rate limit**: Disabled.
diff --git a/doc/architecture/blueprints/gitaly_adaptive_concurrency_limit/index.md b/doc/architecture/blueprints/gitaly_adaptive_concurrency_limit/index.md
index 2bd121a34bb3380959c9908eb608e354e3ff4c37..f3335a0935eff7299142bc246bd82974375b67cc 100644
--- a/doc/architecture/blueprints/gitaly_adaptive_concurrency_limit/index.md
+++ b/doc/architecture/blueprints/gitaly_adaptive_concurrency_limit/index.md
@@ -97,8 +97,8 @@ constraints and distinguishing features, including cgroup utilization and
upload-pack RPC, among others.
The proposed solution does not aim to replace the existing limits in Gitaly
-for [RPC concurrency](../../../administration/gitaly/configure_gitaly.md#limit-rpc-concurrency)
-and [pack object concurrency](../../../administration/gitaly/configure_gitaly.md#limit-pack-objects-concurrency),
+for [RPC concurrency](../../../administration/gitaly/concurrency_limiting.md#limit-rpc-concurrency)
+and [pack object concurrency](../../../administration/gitaly/concurrency_limiting.md#limit-pack-objects-concurrency),
but automatically tweak the parameters. This means
that other aspects, such as queuing, in-queue timeout, queue length,
partitioning, and scoping, will remain unchanged. The proposed solution only
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index bad104081e2fbc27baab48411dcf7306036fc601..f339c58e4cd42a047bcf5ed191fcfdd351ec241a 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -468,7 +468,7 @@ used on GitLab.com.
Per-repository Gitaly RPC concurrency and queuing limits are configured for different types of Git operations such as `git clone`. When these limits are exceeded, a `fatal: remote error: GitLab is currently unable to handle this request due to load` message is returned to the client.
-For administrator documentation, see [limit RPC concurrency](../../administration/gitaly/configure_gitaly.md#limit-rpc-concurrency).
+For administrator documentation, see [limit RPC concurrency](../../administration/gitaly/concurrency_limiting.md#limit-rpc-concurrency).
## GitLab.com logging