diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-07-23 00:09:50 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-07-23 00:09:50 +0300 |
commit | f05ceb978a12b289fe4e3575420b8c9316041e3a (patch) | |
tree | 3c1e7c3cf846e1af0ff0edb5867134ca477b3b58 /config | |
parent | 3ce55b46dfae23d14818ed2630891be8aa3e83e0 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'config')
-rw-r--r-- | config/initializers/database_config.rb | 43 | ||||
-rw-r--r-- | config/initializers/postgres_partitioning.rb | 4 |
2 files changed, 41 insertions, 6 deletions
diff --git a/config/initializers/database_config.rb b/config/initializers/database_config.rb index ce732677c74..79ca6f9354a 100644 --- a/config/initializers/database_config.rb +++ b/config/initializers/database_config.rb @@ -20,11 +20,44 @@ Gitlab.ee do end end -# When running on multi-threaded runtimes like Puma or Sidekiq, -# set the number of threads per process as the minimum DB connection pool size. -# This is to avoid connectivity issues as was documented here: -# https://github.com/rails/rails/pull/23057 -if Gitlab::Runtime.multi_threaded? +# TODO get rid of feature flag https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/495 +if ENV['DB_USE_NEW_POOL_SIZE_LOGIC'] == '1' + # Because of the way Ruby on Rails manages database connections, it is + # important that we have at least as many connections as we have + # threads. While there is a 'pool' setting in database.yml, it is not + # very practical because you need to maintain it in tandem with the + # number of application threads. Because of this we override the number + # of allowed connections in the database connection pool based on the + # configured number of application threads. + # + # Gitlab::Runtime.max_threads is the number of "user facing" application + # threads the process has been configured with. We also have auxiliary + # threads that use database connections. Because it is not practical to + # keep an accurate count of the number auxiliary threads as the + # application evolves over time, we just add a fixed headroom to the + # number of user-facing threads. It is OK if this number is too large + # because connections are instantiated lazily. + + headroom = (ENV["DB_POOL_HEADROOM"].presence || 10).to_i + calculated_pool_size = Gitlab::Runtime.max_threads + headroom + + db_config = Gitlab::Database.config || + Rails.application.config.database_configuration[Rails.env] + + db_config['pool'] = calculated_pool_size + ActiveRecord::Base.establish_connection(db_config) + + Gitlab.ee do + if Gitlab::Runtime.sidekiq? && Gitlab::Geo.geo_database_configured? + Rails.configuration.geo_database['pool'] = calculated_pool_size + Geo::TrackingBase.establish_connection(Rails.configuration.geo_database) + end + end +elsif Gitlab::Runtime.multi_threaded? + # When running on multi-threaded runtimes like Puma or Sidekiq, + # set the number of threads per process as the minimum DB connection pool size. + # This is to avoid connectivity issues as was documented here: + # https://github.com/rails/rails/pull/23057 max_threads = Gitlab::Runtime.max_threads db_config = Gitlab::Database.config || Rails.application.config.database_configuration[Rails.env] diff --git a/config/initializers/postgres_partitioning.rb b/config/initializers/postgres_partitioning.rb index 6c8a72d9bd5..b3f12c2ceb1 100644 --- a/config/initializers/postgres_partitioning.rb +++ b/config/initializers/postgres_partitioning.rb @@ -3,8 +3,10 @@ # Make sure we have loaded partitioned models here # (even with eager loading disabled). +Gitlab::Database::Partitioning::PartitionCreator.register(AuditEventPartitioned) + begin - Gitlab::Database::Partitioning::PartitionCreator.new.create_partitions + Gitlab::Database::Partitioning::PartitionCreator.new.create_partitions unless ENV['DISABLE_POSTGRES_PARTITION_CREATION_ON_STARTUP'] rescue ActiveRecord::ActiveRecordError, PG::Error # ignore - happens when Rake tasks yet have to create a database, e.g. for testing end |