Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
4d0c47058a
commit
d8dd7fa081
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Add keep_divergent_refs to remote_mirrors table
|
||||
merge_request:
|
||||
author:
|
||||
type: other
|
|
@ -0,0 +1,11 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class AddKeepDivergentRefs < ActiveRecord::Migration[6.0]
|
||||
include Gitlab::Database::MigrationHelpers
|
||||
|
||||
DOWNTIME = false
|
||||
|
||||
def change
|
||||
add_column :remote_mirrors, :keep_divergent_refs, :boolean
|
||||
end
|
||||
end
|
|
@ -10,7 +10,7 @@
|
|||
#
|
||||
# It's strongly recommended that you check this file into your version control system.
|
||||
|
||||
ActiveRecord::Schema.define(version: 2020_02_14_034836) do
|
||||
ActiveRecord::Schema.define(version: 2020_02_20_180944) do
|
||||
|
||||
# These are extensions that must be enabled in order to support this database
|
||||
enable_extension "pg_trgm"
|
||||
|
@ -3689,6 +3689,7 @@ ActiveRecord::Schema.define(version: 2020_02_14_034836) do
|
|||
t.boolean "only_protected_branches", default: false, null: false
|
||||
t.string "remote_name"
|
||||
t.boolean "error_notification_sent"
|
||||
t.boolean "keep_divergent_refs"
|
||||
t.index ["last_successful_update_at"], name: "index_remote_mirrors_on_last_successful_update_at"
|
||||
t.index ["project_id"], name: "index_remote_mirrors_on_project_id"
|
||||
end
|
||||
|
|
|
@ -167,7 +167,7 @@ Most workers tend to spend most of their time blocked, wait on network responses
|
|||
from other services such as Redis, Postgres and Gitaly. Since Sidekiq is a
|
||||
multithreaded environment, these jobs can be scheduled with high concurrency.
|
||||
|
||||
Some workers, however, spend large amounts of time _on-cpu_ running logic in
|
||||
Some workers, however, spend large amounts of time _on-CPU_ running logic in
|
||||
Ruby. Ruby MRI does not support true multithreading - it relies on the
|
||||
[GIL](https://thoughtbot.com/blog/untangling-ruby-threads#the-global-interpreter-lock)
|
||||
to greatly simplify application development by only allowing one section of Ruby
|
||||
|
@ -187,13 +187,17 @@ performance.
|
|||
Likewise, if a worker uses large amounts of memory, we can run these on a
|
||||
bespoke low concurrency, high memory fleet.
|
||||
|
||||
Note that Memory-bound workers create heavy GC workloads, with pauses of
|
||||
Note that memory-bound workers create heavy GC workloads, with pauses of
|
||||
10-50ms. This will have an impact on the latency requirements for the
|
||||
worker. For this reason, `memory` bound, `latency_sensitive` jobs are not
|
||||
permitted and will fail CI. In general, `memory` bound workers are
|
||||
discouraged, and alternative approaches to processing the work should be
|
||||
considered.
|
||||
|
||||
If a worker needs large amounts of both memory and CPU time, it should be marked as
|
||||
memory-bound, due to the above restrction on latency-sensitive memory-bound
|
||||
workers.
|
||||
|
||||
## Declaring a Job as CPU-bound
|
||||
|
||||
This example shows how to declare a job as being CPU-bound.
|
||||
|
|
Loading…
Reference in New Issue