From dd4b1df3013606e809cebaf175147ebc901aa106 Mon Sep 17 00:00:00 2001
From: John Cai <jcai@gitlab.com>
Date: Wed, 18 May 2022 00:42:47 +0000
Subject: [PATCH] Remove new cgroups config from docs
This reverts commit a4bd2613adc8de9156908f6d175bf728101d39fd, reversing
changes made to 9c9a8e3d96b69ce5b199d8e672222c716d62a374.
Since the new version of Cgroups is slipping into 15.1, remove the
section about the new configuration.
---
doc/administration/gitaly/configure_gitaly.md | 70 +------------------
1 file changed, 1 insertion(+), 69 deletions(-)
diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index d3b0304eeaaba..6888a2abe9a7d 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -826,7 +826,6 @@ information, see the [relevant documentation](monitoring.md#monitor-gitaly-concu
## Control groups
> - Introduced in GitLab 13.10.
-> - New version of the configuration was introduced in GitLab 15.0.
Gitaly shells out to Git for many of its operations. Git can consume a lot of resources for certain operations,
especially for large repositories.
@@ -857,11 +856,7 @@ Using cgroups allows the kernel to kill these operations before they hog up all
### Configure cgroups in Gitaly
-How you configure cgroups in Gitaly depends on what version of GitLab you use.
-
-#### GitLab 13.10 to GitLab 14.10
-
-To configure cgroups in Gitaly for GitLab versions 13.10 to 14.10, add `gitaly['cgroups']` to `/etc/gitlab/gitlab.rb`. For
+To configure cgroups in Gitaly, add `gitaly['cgroups']` to `/etc/gitlab/gitlab.rb`. For
example:
```ruby
@@ -892,69 +887,6 @@ gitaly['cgroups_cpu_enabled'] = true
which represents 100% of CPU.
which represents 100% of CPU.
-#### GitLab 15.0 and later
-
-To configure cgroups in Gitaly for GitLab versions 15.0 and later, add `gitaly['cgroups']` to `/etc/gitlab/gitlab.rb`. For
-example:
-
-```ruby
-# in /etc/gitlab/gitlab.rb
-gitaly['cgroups_mountpoint'] = "/sys/fs/cgroup"
-gitaly['cgroups_hierarchy_root'] =>"gitaly"
-gitaly['cgroups_memory_bytes'] = 64424509440, # 60gb
-gitaly['cgroups_cpu_shares'] = 1024
-gitaly['cgroups_repositories_count'] => 1000,
-gitaly['cgroups_repositories_memory_bytes'] => 32212254720 # 20gb
-gitaly['cgroups_repositories_cpu_shares'] => 512
-```
-
-- `cgroups_mountpoint` is where the parent cgroup directory is mounted. Defaults to `/sys/fs/cgroup`.
-- `cgroups_hierarchy_root` is the parent cgroup under which Gitaly creates groups, and
- is expected to be owned by the user and group Gitaly runs as. Omnibus GitLab
- creates the set of directories `mountpoint/<cpu|memory>/hierarchy_root`
- when Gitaly starts.
-- `cgroups_memory_bytes` is the total memory limit that is imposed collectively on all
- Git processes that Gitaly spawns. 0 implies no limit.
-- `cgroups_cpu_shares` is the CPU limit that is imposed collectively on all Git
- processes that Gitaly spawns. 0 implies no limit. The maximum is 1024 shares,
- which represents 100% of CPU.
-- `cgroups_repositories_count` is the number of cgroups in the cgroups pool. Each time a new Git
- command is spawned, Gitaly assigns it to one of these cgroups based
- on the repository the command is for. A circular hashing algorithm assigns
- Git commands to these cgroups, so a Git command for a repository is
- always assigned to the same cgroup.
-- `cgroups_repositories_memory_bytes` is the total memory limit that is imposed collectively on all
- Git processes that Gitaly spawns. 0 implies no limit. This value cannot exceed
- that of the top level `cgroups_memory_bytes`.
-- `cgroups_repositories_cpu_shares` is the CPU limit that is imposed collectively on all Git
- processes Gitaly spawns. 0 implies no limit. The maximum is 1024 shares,
- which represents 100% of CPU. This value cannot exceed that of the top
- level`cgroups_cpu_shares`.
-
-The difference in the cgroups configuration in GitLab 15.0 and later is that we create a pool of cgroups that are isolated
-based on the repository used in the Git command to be placed under one of these cgroups.
-
-### Configuring oversubscription
-
-In the previous example configuration for GitLab 15.0 and later:
-
-- The top level memory limit is capped at 60gb.
-- Each of the 1000 cgroups in the repositories pool is capped at 20gb.
-
-This is called "oversubscription". Each cgroup in the pool has a much larger capacity than 1/1000th
-of the top-level memory limit.
-
-This strategy has two main benefits:
-
-- It gives the host protection from overall memory starvation (OOM), because the top-level
- cgroup's memory limit can be set to a threshold smaller than the host's
- capacity. Processes outside of that cgroup are not at risk of OOM.
-- It allows each individual cgroup in the pool to burst up to a generous upper
- bound (in this example 20 GB) that is smaller than the parent cgroup's limit,
- but substantially larger than 1/N of the parent's limit. In this example, up
- to 3 child cgroups can concurrently burst up to their max. In general, all
- 1000 cgroups would use much less than the 20 GB.
-
## Background Repository Optimization
Empty directories and unneeded configuration settings may accumulate in a repository and
--
GitLab