Ubuntu 下对 GitLab 进行性能测试与监控
一 测试流程与指标
- 明确目标与场景：优先覆盖对性能最敏感的链路，如仓库克隆（HTTPS/SSH）、代码推送（Push）、Web 页面与 API 列表/搜索、以及CI 流水线并发。
- 基线先行：在变更前后各留出至少24 小时的稳定观测窗口，便于对比。
- 指标口径统一：报告至少包含平均响应时间（ART/Mean）、95 百分位（p95）、99 百分位（p99）与错误率；同时采集CPU、内存、磁盘 IOPS/吞吐、网络等系统资源。
- 工具组合：用GitLab Performance Tool（GPT）模拟真实 Git 操作，用Prometheus + Grafana采集与可视化 GitLab 内置指标，必要时补充分布式追踪/请求剖析定位瓶颈。
二 环境准备与监控搭建
- 启用 GitLab 指标端点（Omnibus 示例）：在 /etc/gitlab/gitlab.rb 中开启监控相关组件，然后执行 gitlab-ctl reconfigure。
- 关键开关：
- gitlab_rails[‘monitoring_enabled’] = true
- sidekiq[‘metrics_enabled’] = true
- gitlab_exporter[‘enable’] = true
- puma[‘exporter_enabled’] = true
- nginx[‘status’][‘enable’] = true
- unicorn[‘enable’] = false（如使用 Puma）
- Prometheus 采集：添加 GitLab 各组件 job（如 gitlab-rails、sidekiq、puma、nginx、gitlab-exporter）的 /metrics 抓取；Grafana 导入 GitLab 官方或自建面板，统一查看请求耗时 p50/p95/p99、错误率、队列长度、作业延迟等。
- 节点级监控：安装 collectl / Netdata 观察CPU、内存、磁盘 IOPS/吞吐、网络；Kubernetes 场景可用 ServiceMonitor/PodMonitor 或注解自动发现抓取。
三 负载与场景测试
- 推荐工具与场景
- Git 操作负载：GitLab Performance Tool（GPT）发起克隆、拉取、推送、Web 列表/搜索等混合场景，便于得到接近真实业务的p50/p95/p99与错误率。
- HTTP API/页面：使用 JMeter 编写脚本，覆盖登录、项目/分支列表、搜索、创建 Issue、API 调用等，支持并发用户数与持续时间阶梯加压。
- 持续推送场景：模拟多用户、多仓库、持续 5–15 分钟的随机大小推送，观察排队、超时、错误率与后端资源变化。
- 示例 JMeter 场景要点
- 线程组：设置线程数=并发用户、Ramp-Up 时间、循环次数/持续时间。
- HTTP 请求：配置 HTTPS/SSH 克隆 URL、Authorization 头（PAT 或 SSH Key）、提交内容大小分布。
- 监听器：聚合报告/图形结果，输出ART、Throughput、Error%；分布式测试可结合 JMeter 分布式模式。
- 结果记录：每个场景至少记录p50/p95/p99、错误率、峰值资源占用，并与基线对比。
四 存储与 I/O 基准测试
- 仓库与 NFS/Gitaly 存储对 Git 操作影响最大，建议用 fio 对数据盘/NFS 做基准测试（在 Git 数据目录或挂载点执行）。
- 安装与命令示例：
- 安装：sudo apt install fio
- 随机读写（贴近 Git 元数据/对象访问）：
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test \
–bs=4k --iodepth=64 --readwrite=randrw --rwmixread=75 --size=4G \
–filename=/path/to/git-data/testfile
- 关键输出：iops（读/写）、带宽（MB/s）、延迟分布；测试完成后删除测试文件。
- 解读与参考：SSD 在该负载下通常可达数万 IOPS，而机械盘往往只有千级 IOPS量级；若 IOPS/延迟不达标，优先检查存储类型、挂载选项、队列深度、I/O 调度器等。
五 结果分析与优化建议
- 判定标准：当p95/p99明显上升、错误率升高且资源未达瓶颈时，优先排查数据库慢查询、锁争用、Sidekiq 队列堆积、反向代理/网络；若资源达瓶颈，则考虑水平扩展（Puma/Unicorn 工作进程、Sidekiq 并发）、数据库/缓存分离、更快存储（NVMe/本地 SSD）。
- 变更验证：优化后重复相同场景，保持≥24 小时观测窗口，对比p50/p95/p99、错误率与资源曲线，确认收益与回归。
- 风险提示：压测会对实例产生负载，建议在非生产或维护窗口进行，避免影响真实业务；对生产环境仅做短时、低强度的“冒烟型”验证，并提前做好备份与回滚预案。