Ubuntu 上 GitLab 的常见性能瓶颈与定位路径
一、硬件与存储层
- 存储 I/O 是最常见瓶颈：Git 操作（clone、fetch、push、LFS）对磁盘随机 I/O 与延迟极敏感，使用 HDD 或网络挂载（如 NFS）时更易出现页面卡顿、操作超时；升级为 SSD/NVMe 通常能立竿见影。对象存储适合附件与备份，但不应替代仓库本体的高性能本地盘。
- 资源基线偏低会放大瓶颈：在 2 核 4GB 等低配环境下，默认启用的组件较多（如监控、日志、Sidekiq 等），CPU/内存竞争激烈，易出现 CPU 100%、请求排队、页面超时等现象。
- 参考基线（经验值）：CPU/内存不足会显著限制并发能力，例如从 2 核 提升到 4 核、8 核 能支持的用户规模会大幅上升；低于 4GB 可用内存 不建议用于生产。以上因素叠加时，最先表现为仓库操作变慢、CI 排队、Web 响应抖动。
二、组件与配置层
- 默认启用过多非核心组件：监控链路（Prometheus、Alertmanager、node_exporter、postgres_exporter、redis_exporter 等）会占用可观的 CPU/内存/磁盘 I/O，在中小规模实例中尤为明显。按需关闭可释放资源。
- Web/后台并发与队列：前端 Puma 线程/进程、后台 Sidekiq 并发配置过小会造成排队，过大则引发上下文切换与内存膨胀。常见做法是按负载逐步调优（如 Puma 进程数≈CPU 核数、Sidekiq 并发从 4–10 起步）。
- 数据库与缓存：PostgreSQL 的 shared_buffers、work_mem 过小会放大查询/写入延迟；Redis 作为请求与 Sidekiq 的“中枢”，连接与内存不足会导致任务积压与超时。对象存储用于大文件可减轻本地盘压力。
- 版本与特性：旧版本可能存在已知性能问题；启用如 实时代码分析 等重特性会显著增加 CPU 占用，必要时可关闭或限流。
三、网络与连接层
- 传输协议与连接复用：启用 HTTP/2 与合理的 Keep-Alive 可降低握手与连接开销；对外部访问可结合 CDN 加速静态资源。
- TCP 栈与端口：适当优化 net.core.somaxconn、net.ipv4.ip_local_port_range、tcp_tw_reuse、tcp_fin_timeout 等参数，有助于缓解高并发下的连接耗尽与时延波动（需结合监控谨慎调整）。
- 带宽与延迟：跨地域访问、代理/防火墙/NAT 链路抖动都会放大 Git 大对象传输的时延，表现为 clone/push 缓慢或中断。
四、快速定位与优化优先级
- 监控先行：启用或对接 Prometheus + Grafana，重点观察 Puma/Unicorn 队列、Sidekiq 排队与重试、PostgreSQL 连接/慢查询、Redis 命中率与内存、磁盘 IOPS/延迟、网络丢包/重传。
- 先做“低成本高收益”调整：
- 存储：迁移至 SSD/NVMe；大附件/备份改用对象存储。
- 组件：在中小规模或资源紧张环境，关闭不必要的 监控/导出器 与重特性（如实时代码分析）。
- 并发：按负载调小/调大 Puma 与 Sidekiq 并发，避免“过少排队/过多抖动”。
- 数据库：为 PostgreSQL 设置合理的 shared_buffers/work_mem，并定期 VACUUM/分析；保障 Redis 内存与连接数。
- 网络：启用 HTTP/2/Keep-Alive，必要时优化 TCP 参数与对外 CDN。
- 迭代验证：每次变更后观察 ART/吞吐/错误率 与资源利用率，逐步逼近最优配置。
