Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
李少辉-开发者
gitlab-foss
提交
5095e0cf
G
gitlab-foss
项目概览
李少辉-开发者
/
gitlab-foss
通知
15
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
gitlab-foss
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
提交
5095e0cf
编写于
8月 26, 2019
作者:
J
Jacob Vosmaer
提交者:
Achilleas Pipinellis
8月 26, 2019
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Add documentation about Gitaly concurrency limiter
上级
67ac55cc
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
41 addition
and
0 deletion
+41
-0
doc/administration/gitaly/index.md
doc/administration/gitaly/index.md
+41
-0
未找到文件。
doc/administration/gitaly/index.md
浏览文件 @
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
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录