Ubuntu 上 GitLab 性能监控与调优实战
一 监控体系与关键指标
- 系统层工具
- 使用 top/htop、vmstat、iostat、sar、netstat 快速定位 CPU、内存、磁盘 I/O、网络 的异常波动，配合 Glances 做整体资源巡检。
- GitLab 自带能力
- 启用 Monitoring 项目 查看实例健康面板；在 管理员 → 设置 → 度量与剖析 打开 Performance Bar，定位单次请求的耗时构成（如数据库、Gitaly、Rails）。
- 时序与可视化
- 使用 Prometheus 采集 GitLab 组件指标，配合 Grafana 展示与告警；可自建抓取任务或复用 GitLab 内建采集器，面板导入 GitLab 官方或社区模板以快速落地。
二 快速定位瓶颈
- 资源类
- CPU 持续打满：检查 Puma/Sidekiq 并发是否过高、是否存在慢查询或 CI 并发风暴。
- 内存吃紧：关注 Puma/Unicorn、Sidekiq、PostgreSQL、Redis 的常驻集；避免 swap 抖动引发延迟。
- 磁盘 I/O 高：观察 iostat -x 1 的 await、svctm、util，确认是否为 Git 仓库、PostgreSQL WAL/数据、Sidekiq 队列 导致。
- 网络：大仓库克隆慢或 CI 拉取慢，排查 带宽、丢包、TCP 重传 与反向代理配置。
- 组件类
- Rails/Puma：页面打开慢、接口超时，结合 Performance Bar 看各阶段耗时，核对 数据库索引/语句 与 外部依赖。
- Sidekiq：任务堆积、延迟高，检查 并发数、失败重试、任务类型（如邮件、Webhook、流水线） 是否异常。
- Gitaly：仓库操作慢，关注 Gitaly 节点负载、磁盘 I/O、网络延迟，必要时扩容或分离高负载仓库。
- PostgreSQL：慢查询、锁等待、连接数打满，结合 pg_stat_statements 与慢查询日志优化。
- Redis：内存膨胀、命中率下降，检查 键过期策略 与 大 key。
三 配置调优清单
- 基础环境
- 使用 SSD/NVMe，分离 Git 仓库数据、PostgreSQL 数据、日志 到不同磁盘；公网静态资源启用 CDN 加速。
- 大文件（如二进制、设计稿）使用 Git LFS 或对象存储，避免仓库膨胀与克隆耗时。
- GitLab 组件参数（/etc/gitlab/gitlab.rb，修改后执行 gitlab-ctl reconfigure）
- Web 与后台并发
- 适度调整 Puma worker_processes / threads 与 Sidekiq concurrency，避免与 CPU/内存争用；生产不建议关闭 Puma 的 cluster 模式。
- 缓存与会话
- 启用 Redis 作为缓存与会话后端（默认集成）；可按需评估 Memcached 分担读多写少场景。
- 数据库（PostgreSQL）
- 使用受支持的 PostgreSQL 版本；结合内存与负载设置 shared_buffers、work_mem、effective_cache_size、max_connections，并定期执行 VACUUM/ANALYZE 与慢查询优化。
- 存储与对象存储
- 将 上传附件、LFS、备份 等迁移至 对象存储（如 S3/MinIO），降低本地磁盘压力与备份窗口。
- 版本与维护
- 保持 GitLab 版本 与补丁更新，获取性能修复与新特性；定期清理无用仓库、分支与日志，减少膨胀。
四 告警与容量规划
- 告警规则示例（Prometheus）
- CPU 持续高占用：expr: 1 - avg by(instance)(rate(node_cpu_seconds_total{mode=“idle”}[5m])) > 0.8；for: 5m；labels.severity: warning
- 内存使用率高：expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) > 0.85；for: 5m
- 磁盘空间不足：expr: 1 - (node_filesystem_avail_bytes{fstype!~“tmpfs|overlay”} / node_filesystem_size_bytes{fstype!~“tmpfs|overlay”}) > 0.10
- PostgreSQL 慢查询：expr: rate(pg_stat_statements_time_seconds_total[1m]) > 1（按业务调阈值）
- Sidekiq 队列堆积：expr: sidekiq_queue_size{queue=“default”} > 100（按队列与 SLO 调整）
- 容量基线建议
- 小型团队：CPU ≥ 4 核、内存 ≥ 8–16GB、SSD；公网带宽 ≥ 100Mbps。
- 中大型团队：CPU 多核高主频、内存 ≥ 32GB、NVMe SSD；数据库与仓库分离部署，必要时引入 负载均衡/多实例。
五 常见场景与优化组合
- 小型实例或开发环境（资源紧张）
- 适度下调 Puma/Sidekiq 并发，降低 PostgreSQL shared_buffers/work_mem；必要时可临时关闭非核心监控组件（如 monitoring_role/prometheus/alertmanager/exporters）以节省内存，但需评估可观测性损失与稳定性影响。
- 高并发与大规模仓库
- 提升 Puma 进程/线程 与 Sidekiq 并发；为 PostgreSQL 分配合理 shared_buffers 与连接池；将 附件/LFS/备份 迁移至对象存储；公网静态资源走 CDN；必要时 水平扩展 GitLab 组件与数据库读写分离。
