ubuntu gitlab性能监控与调优

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 组件与数据库读写分离。