diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2019-11-18 12:06:03 +0000 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2019-11-18 12:06:03 +0000 |
| commit | 16d9f66e9651d35b52e5a167789befe7b861292c (patch) | |
| tree | 38ffe73aeffa5bc8ceaa3357db302edce6d874f6 /doc/update | |
| parent | 5333cb6c7c960aac58af40c898c87d050d829383 (diff) | |
| download | gitlab-ce-16d9f66e9651d35b52e5a167789befe7b861292c.tar.gz | |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/update')
| -rw-r--r-- | doc/update/README.md | 8 |
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 |