Add latest changes from gitlab-org/gitlab@13-3-stable-ee

6 files changed, 30 insertions, 28 deletions

diff --git a/doc/administration/operations/cleaning_up_redis_sessions.md b/doc/administration/operations/cleaning_up_redis_sessions.md
index 38fac8a0eca..d2aec2f7c47 100644
--- a/doc/administration/operations/cleaning_up_redis_sessions.md
+++ b/doc/administration/operations/cleaning_up_redis_sessions.md
@@ -15,7 +15,8 @@ prefixed with `session:gitlab:`, so they would look like
 `session:gitlab:976aa289e2189b17d7ef525a6702ace9`. Below we describe how to
 remove the keys in the old format.
 
-**Note:** the instructions below must be modified in accordance with your
+NOTE: **Note:**
+The instructions below must be modified in accordance with your
 configuration settings if you have used the advanced Redis
 settings outlined in
 [Configuration Files Documentation](https://gitlab.com/gitlab-org/gitlab/blob/master/config/README.md).
diff --git a/doc/administration/operations/extra_sidekiq_processes.md b/doc/administration/operations/extra_sidekiq_processes.md
index 155680354da..e589ecc4216 100644
--- a/doc/administration/operations/extra_sidekiq_processes.md
+++ b/doc/administration/operations/extra_sidekiq_processes.md
@@ -82,7 +82,7 @@ To start multiple processes:
    ```
 
 After the extra Sidekiq processes are added, navigate to
-**{admin}** **Admin Area > Monitoring > Background Jobs** (`/admin/background_jobs`) in GitLab.
+**Admin Area > Monitoring > Background Jobs** (`/admin/background_jobs`) in GitLab.
 
 ![Multiple Sidekiq processes](img/sidekiq-cluster.png)
 
diff --git a/doc/administration/operations/filesystem_benchmarking.md b/doc/administration/operations/filesystem_benchmarking.md
index 856061348ed..64afd1b44f3 100644
--- a/doc/administration/operations/filesystem_benchmarking.md
+++ b/doc/administration/operations/filesystem_benchmarking.md
@@ -26,7 +26,7 @@ To install:
 Then run the following:
 
 ```shell
-fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/path/to/git-data/testfile --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
+fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=4k --iodepth=64 --readwrite=randrw --rwmixread=75 --size=4G --filename=/path/to/git-data/testfile
 ```
 
 This will create a 4GB file in `/path/to/git-data/testfile`. It performs
diff --git a/doc/administration/operations/moving_repositories.md b/doc/administration/operations/moving_repositories.md
index 960005fe25d..4763c012538 100644
--- a/doc/administration/operations/moving_repositories.md
+++ b/doc/administration/operations/moving_repositories.md
@@ -9,16 +9,17 @@ We will look at three scenarios: the target directory is empty, the
 target directory contains an outdated copy of the repositories, and
 how to deal with thousands of repositories.
 
-**Each of the approaches we list can/will overwrite data in the
+DANGER: **Danger:**
+Each of the approaches we list can/will overwrite data in the
 target directory `/mnt/gitlab/repositories`. Do not mix up the
-source and the target.**
+source and the target.
 
-## Target directory is empty: use a tar pipe
+## Target directory is empty: use a `tar` pipe
 
 If the target directory `/mnt/gitlab/repositories` is empty the
-simplest thing to do is to use a tar pipe. This method has low
-overhead and tar is almost always already installed on your system.
-However, it is not possible to resume an interrupted tar pipe: if
+simplest thing to do is to use a `tar` pipe. This method has low
+overhead and `tar` is almost always already installed on your system.
+However, it is not possible to resume an interrupted `tar` pipe: if
 that happens then all data must be copied again.
 
 ```shell
@@ -28,9 +29,9 @@ sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\
 
 If you want to see progress, replace `-xf` with `-xvf`.
 
-### Tar pipe to another server
+### `tar` pipe to another server
 
-You can also use a tar pipe to copy data to another server. If your
+You can also use a `tar` pipe to copy data to another server. If your
 `git` user has SSH access to the new server as `git@newserver`, you
 can pipe the data through SSH.
 
@@ -42,13 +43,13 @@ sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\
 If you want to compress the data before it goes over the network
 (which will cost you CPU cycles) you can replace `ssh` with `ssh -C`.
 
-## The target directory contains an outdated copy of the repositories: use rsync
+## The target directory contains an outdated copy of the repositories: use `rsync`
 
 If the target directory already contains a partial / outdated copy
 of the repositories it may be wasteful to copy all the data again
-with tar. In this scenario it is better to use rsync. This utility
+with `tar`. In this scenario it is better to use `rsync`. This utility
 is either already installed on your system or easily installable
-via apt, yum etc.
+via `apt`, `yum`, etc.
 
 ```shell
 sudo -u git  sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \
@@ -59,30 +60,30 @@ The `/.` in the command above is very important, without it you can
 easily get the wrong directory structure in the target directory.
 If you want to see progress, replace `-a` with `-av`.
 
-### Single rsync to another server
+### Single `rsync` to another server
 
 If the `git` user on your source system has SSH access to the target
-server you can send the repositories over the network with rsync.
+server you can send the repositories over the network with `rsync`.
 
 ```shell
 sudo -u git sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \
   git@newserver:/mnt/gitlab/repositories'
 ```
 
-## Thousands of Git repositories: use one rsync per repository
+## Thousands of Git repositories: use one `rsync` per repository
 
-Every time you start an rsync job it has to inspect all files in
+Every time you start an `rsync` job it has to inspect all files in
 the source directory, all files in the target directory, and then
 decide what files to copy or not. If the source or target directory
-has many contents this startup phase of rsync can become a burden
-for your GitLab server. In cases like this you can make rsync's
+has many contents this startup phase of `rsync` can become a burden
+for your GitLab server. In cases like this you can make `rsync`'s
 life easier by dividing its work in smaller pieces, and sync one
 repository at a time.
 
-In addition to rsync we will use [GNU
+In addition to `rsync` we will use [GNU
 Parallel](http://www.gnu.org/software/parallel/). This utility is
-not included in GitLab so you need to install it yourself with apt
-or yum. Also note that the GitLab scripts we used below were added
+not included in GitLab so you need to install it yourself with `apt`
+or `yum`. Also note that the GitLab scripts we used below were added
 in GitLab 8.1.
 
 **This process does not clean up repositories at the target location that no
@@ -90,9 +91,9 @@ longer exist at the source.** If you start using your GitLab instance with
 `/mnt/gitlab/repositories`, you need to run `gitlab-rake gitlab:cleanup:repos`
 after switching to the new repository storage directory.
 
-### Parallel rsync for all repositories known to GitLab
+### Parallel `rsync` for all repositories known to GitLab
 
-This will sync repositories with 10 rsync processes at a time. We keep
+This will sync repositories with 10 `rsync` processes at a time. We keep
 track of progress so that the transfer can be restarted if necessary.
 
 First we create a new directory, owned by `git`, to hold transfer
@@ -147,7 +148,7 @@ cat /home/git/transfer-logs/* | sort | uniq -u |\
 `
 ```
 
-### Parallel rsync only for repositories with recent activity
+### Parallel `rsync` only for repositories with recent activity
 
 Suppose you have already done one sync that started after 2015-10-1 12:00 UTC.
 Then you might only want to sync repositories that were changed via GitLab
diff --git a/doc/administration/operations/puma.md b/doc/administration/operations/puma.md
index 62b93d40a6b..e7b4bb88faf 100644
--- a/doc/administration/operations/puma.md
+++ b/doc/administration/operations/puma.md
@@ -27,7 +27,7 @@ will _not_ carry over automatically, due to differences between the two applicat
 deployments, see [Configuring Puma Settings](https://docs.gitlab.com/omnibus/settings/puma.html#configuring-puma-settings).
 For Helm based deployments, see the [Webservice Chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
 
-Additionally we strongly recommend that multi-node deployments [configure their load balancers to utilize the readiness check](../high_availability/load_balancer.md#readiness-check) due to a difference between Unicorn and Puma in how they handle connections during a restart of the service.
+Additionally we strongly recommend that multi-node deployments [configure their load balancers to utilize the readiness check](../load_balancer.md#readiness-check) due to a difference between Unicorn and Puma in how they handle connections during a restart of the service.
 
 ## Performance caveat when using Puma with Rugged
 
diff --git a/doc/administration/operations/sidekiq_memory_killer.md b/doc/administration/operations/sidekiq_memory_killer.md
index fdccfacc8a9..e829d735c4f 100644
--- a/doc/administration/operations/sidekiq_memory_killer.md
+++ b/doc/administration/operations/sidekiq_memory_killer.md
@@ -71,5 +71,5 @@ The MemoryKiller is controlled using environment variables.
 
   If the process hard shutdown/restart is not performed by Sidekiq,
   the Sidekiq process will be forcefully terminated after
-  `Sidekiq.options[:timeout] * 2` seconds. An external supervision mechanism
+  `Sidekiq.options[:timeout] + 2` seconds. An external supervision mechanism
   (e.g. runit) must restart Sidekiq afterwards.