doc/administration/geo/replication/tuning.md
{{< details >}}
{{< /details >}}
You can limit the number of concurrent operations the sites can run in the background.
On the primary site:
In the upper-right corner, select Admin.
In the left sidebar, select Geo > Sites.
Select Edit of the secondary site you want to tune.
Under Tuning settings, there are several variables that can be tuned to improve the performance of Geo:
Increasing the concurrency values increases the number of jobs that are scheduled. However, this may not lead to more downloads in parallel unless the number of available Sidekiq threads is also increased. For example, if repository synchronization concurrency is increased from 25 to 50, you may also want to increase the number of Sidekiq threads from 25 to 50. See the Sidekiq concurrency documentation for more details.
[!note] The Verification concurrency limit is a single global limit on the total number of verification jobs that run concurrently on a site, across all data types combined. The effective concurrency equals the value you configure.
In GitLab 19.2 and earlier, GitLab divided the configured value by the number of data types before applying it, so the effective concurrency was lower than the value you set. When you upgrade to GitLab 19.3, GitLab rescales each site's stored value so the effective concurrency stays roughly the same as before the upgrade. As a result, the stored value might be lower after upgrading. Review and re-tune it as needed.
To avoid excessive load when setting up new Geo sites, starting with GitLab 18.0, Geo's concurrency settings are set to low defaults for most environments. To increase these settings: