Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
1
Merge Requests
1
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
nexedi
gitlab-ce
Commits
5095e0cf
Commit
5095e0cf
authored
Aug 26, 2019
by
Jacob Vosmaer
Committed by
Achilleas Pipinellis
Aug 26, 2019
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add documentation about Gitaly concurrency limiter
parent
67ac55cc
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
41 additions
and
0 deletions
+41
-0
doc/administration/gitaly/index.md
doc/administration/gitaly/index.md
+41
-0
No files found.
doc/administration/gitaly/index.md
View file @
5095e0cf
...
...
@@ -518,6 +518,47 @@ One current feature of GitLab that still requires a shared directory (NFS) is
There is
[
work in progress
](
https://gitlab.com/gitlab-org/gitlab-pages/issues/196
)
to eliminate the need for NFS to support GitLab Pages.
## Limiting RPC concurrency
It can happen that CI clone traffic puts a large strain on your Gitaly
service. The bulk of the work gets done in the SSHUploadPack (for Git
SSH) and PostUploadPack (for Git HTTP) RPC's. To prevent such workloads
from overcrowding your Gitaly server you can set concurrency limits in
Gitaly's configuration file.
```
ruby
# in /etc/gitlab/gitlab.rb
gitaly
[
'concurrency'
]
=
[
{
'rpc'
=>
"/gitaly.SmartHTTPService/PostUploadPack"
,
'max_per_repo'
=>
20
},
{
'rpc'
=>
"/gitaly.SSHService/SSHUploadPack"
,
'max_per_repo'
=>
20
}
]
```
This will limit the number of in-flight RPC calls for the given RPC's.
The limit is applied per repository. In the example above, each on the
Gitaly server can have at most 20 simultaneous PostUploadPack calls in
flight, and the same for SSHUploadPack. If another request comes in for
a repository that hase used up its 20 slots, that request will get
queued.
You can observe the behavior of this queue via the Gitaly logs and via
Prometheus. In the Gitaly logs, you can look for the string (or
structured log field)
`acquire_ms`
. Messages that have this field are
reporting about the concurrency limiter. In Prometheus, look for the
`gitaly_rate_limiting_in_progress`
,
`gitaly_rate_limiting_queued`
and
`gitaly_rate_limiting_seconds`
metrics.
The name of the Prometheus metric is not quite right because this is a
concurrency limiter, not a rate limiter. If a client makes 1000 requests
in a row in a very short timespan, the concurrency will not exceed 1,
and this mechanism (the concurrency limiter) will do nothing.
## Troubleshooting Gitaly
### Commits, pushes, and clones return a 401
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment