diff options
| -rw-r--r-- | doc/development/gitaly.md | 32 | ||||
| -rw-r--r-- | lib/gitlab/gitaly_client.rb | 2 |
2 files changed, 32 insertions, 2 deletions
diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md index f0be3a6b141..e41d258bec6 100644 --- a/doc/development/gitaly.md +++ b/doc/development/gitaly.md @@ -12,6 +12,7 @@ status of the migration. Gitaly makes heavy use of [feature flags](feature_flags.md). Each Rugged-to-Gitaly migration goes through a [series of phases](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/MIGRATION_PROCESS.md): + * **Opt-In**: by default the Rugged implementation is used. * Production instances can choose to enable the Gitaly endpoint by enabling the feature flag. * For testing purposes, you may wish to enable all feature flags by default. This can be done by exporting the following @@ -19,7 +20,7 @@ Each Rugged-to-Gitaly migration goes through a [series of phases](https://gitlab * On developer instances (ie, when `Rails.env.development?` is true), the Gitaly endpoint is enabled by default, but can be _disabled_ using feature flags. * **Opt-Out**: by default, the Gitaly endpoint is used, but the feature can be explicitly disabled using the feature flag. -* **Madatory**: The migration is complete and cannot be disabled. The old codepath is removed. +* **Mandatory**: The migration is complete and cannot be disabled. The old codepath is removed. ### Enabling and Disabling Feature @@ -49,6 +50,35 @@ If your test-suite is failing with Gitaly issues, as a first step, try running: rm -rf tmp/tests/gitaly ``` +## `TooManyInvocationsError` errors + +During development and testing, you may experience `Gitlab::GitalyClient::TooManyInvocationsError` failures. +The `GitalyClient` will attempt to block against potential n+1 issues by raising this error +when Gitaly is called more than 30 times in a single Rails request or Sidekiq execution. + +As a temporary measure, export `GITALY_DISABLE_REQUEST_LIMITS=1` to suppress the error. This will disable the n+1 detection +in your development environment. + +Please raise an issue in the GitLab CE or EE repositories to report the issue. Include the labels ~Gitaly +~performance ~"technical debt". Please ensure that the issue contains the full stack trace and error message of the +`TooManyInvocationsError`. Also include any known failing tests if possible. + +Isolate the source of the n+1 problem. This will normally be a loop that results in Gitaly being called for each +element in an array. If you are unable to isolate the problem, please contact a member +of the [Gitaly Team](https://gitlab.com/groups/gl-gitaly/group_members) for assistance. + +Once the source has been found, wrap it in an `allow_n_plus_1_calls` block, as follows: + +```ruby +# n+1: link to n+1 issue +Gitlab::GitalyClient.allow_n_plus_1_calls do + # original code + commits.each { |commit| ... } +end +``` + +Once the code is wrapped in this block, this code-path will be excluded from n+1 detection. + --- [Return to Development documentation](README.md) diff --git a/lib/gitlab/gitaly_client.rb b/lib/gitlab/gitaly_client.rb index 955d2307f88..e75e0500ed8 100644 --- a/lib/gitlab/gitaly_client.rb +++ b/lib/gitlab/gitaly_client.rb @@ -151,7 +151,7 @@ module Gitlab actual_call_count = increment_call_count("gitaly_#{call_site}_actual") # Do no enforce limits in production - return if Rails.env.production? + return if Rails.env.production? || ENV["GITALY_DISABLE_REQUEST_LIMITS"] # Check if this call is nested within a allow_n_plus_1_calls # block and skip check if it is |