diff options
author | Andrew Newdigate <andrew@gitlab.com> | 2017-09-30 19:26:23 +0300 |
---|---|---|
committer | Robert Speicher <robert@gitlab.com> | 2017-09-30 19:26:23 +0300 |
commit | 2146d6253fadfec82e58d66e59b9ec50fdf3d761 (patch) | |
tree | 87223ef0f2af0e1ee2a3e25188a37fd05da838dc /doc/development/gitaly.md | |
parent | 0781e956e4a4174494aa28b62b8dfc92a92e8e84 (diff) |
Add environment variable to bypass n+1
Diffstat (limited to 'doc/development/gitaly.md')
-rw-r--r-- | doc/development/gitaly.md | 32 |
1 files changed, 31 insertions, 1 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) |