summaryrefslogtreecommitdiff
path: root/doc/update
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2019-11-18 12:06:03 +0000
committerGitLab Bot <gitlab-bot@gitlab.com>2019-11-18 12:06:03 +0000
commit16d9f66e9651d35b52e5a167789befe7b861292c (patch)
tree38ffe73aeffa5bc8ceaa3357db302edce6d874f6 /doc/update
parent5333cb6c7c960aac58af40c898c87d050d829383 (diff)
downloadgitlab-ce-16d9f66e9651d35b52e5a167789befe7b861292c.tar.gz
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/update')
-rw-r--r--doc/update/README.md8
1 files changed, 7 insertions, 1 deletions
diff --git a/doc/update/README.md b/doc/update/README.md
index 965f29bc8aa..6834deb1a85 100644
--- a/doc/update/README.md
+++ b/doc/update/README.md
@@ -69,7 +69,13 @@ before continuing the upgrading procedure. While this won't require downtime
between upgrading major/minor releases, allowing the background migrations to
finish. The time necessary to complete these migrations can be reduced by
increasing the number of Sidekiq workers that can process jobs in the
-`background_migration` queue.
+`background_migration` queue. To check the size of this queue,
+[start a Rails console session](https://docs.gitlab.com/omnibus/maintenance/#starting-a-rails-console-session)
+and run the command below:
+
+```ruby
+Sidekiq::Queue.new('background_migration').size
+```
As a rule of thumb, any database smaller than 10 GB won't take too much time to
upgrade; perhaps an hour at most per minor release. Larger databases however may