GitLab内存占用过高排查与优化实战：从95%到稳定运行的完整指南

用户8589624

发布于 2025-11-16 08:54:09

1130

文章被收录于专栏：nginxnginx

《GitLab内存占用过高排查与优化实战：从95%到稳定运行的完整指南》

引言

在运维GitLab时，内存占用过高是常见问题。最近，一台运行GitLab的CentOS7服务器内存使用率飙升至95%以上，导致系统响应缓慢。本文将详细记录整个排查过程、问题分析、解决方案及优化建议，帮助遇到类似问题的开发者快速定位和解决问题。

1. 问题现象

服务器配置：15GB内存，CentOS7，GitLab社区版
症状：
- free -h 显示内存使用13GB/15GB（95%+）
- 无Swap空间（Swap: 0B）
- top 和 ps aux 显示多个Puma进程占用大量内存

2. 初步排查

2.1 检查系统内存

free -h

输出：

              total        used        free      shared  buff/cache   available
Mem:            15G         13G        263M        154M        991M        761M
Swap:            0B          0B          0B

结论：内存几乎耗尽，且无Swap缓冲。

2.2 查看高内存进程

ps aux --sort=-%mem | head -20

关键输出：

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
git      25624  0.4 22.2 5604100 3534936 ?     Sl   Feb28 550:42 puma: cluster worker 3
git      18003  0.4 20.9 5427464 3337344 ?     Sl   Mar22 468:42 puma: cluster worker 2
git       2165  0.2 19.7 5096760 3138504 ?     Sl    2024 810:45 puma: cluster worker 0
git      21320  0.3 19.1 4920068 3052844 ?     Sl    2024 751:22 puma: cluster worker 1

结论：4个Puma worker共占用 ~12.6GB 内存，是主要问题。

3. 问题分析

3.1 Puma内存泄漏

GitLab默认使用Puma作为Web服务器，其Worker会随请求增长占用内存。
该服务器Puma worker已运行 200+天，存在明显内存泄漏。

3.2 无Swap空间

系统未配置Swap，导致内存耗尽时直接触发OOM（Out of Memory）。

3.3 Sidekiq和PostgreSQL

Sidekiq占用 960MB，但仍在合理范围。
PostgreSQL内存使用正常（<100MB），不是主要问题。

4. 解决方案

4.1 紧急措施

(1) 重启Puma释放内存

sudo gitlab-ctl restart puma

效果：立即释放 ~12GB 内存。

(2) 创建Swap空间

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

作用：防止内存耗尽时系统崩溃。

4.2 长期优化

(1) 调整Puma配置

编辑 /etc/gitlab/gitlab.rb：

# 减少Worker数量
puma['worker_processes'] = 2

# 限制单个Worker内存
puma['worker_memory_limit_min'] = "1024MB"
puma['worker_memory_limit_max'] = "2048MB"

# 启用内存杀手（自动重启泄漏的Worker）
puma['worker_memory_killer'] = {
  'max_requests' => 5000,
  'max_ram' => "2048MB",
  'check_interval' => 60
}

应用配置：

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

(2) 优化Sidekiq

sidekiq['max_concurrency'] = 15  # 默认25，减少并发数
sidekiq['min_concurrency'] = 5

(3) 监控与自动化

安装 htop 实时监控：

sudo yum install htop

设置每日自动重启Puma（防止长期运行泄漏）：

crontab -e

添加：

0 3 * * * /usr/bin/gitlab-ctl restart puma

5. 效果验证

优化措施	内存变化	风险
重启Puma	13GB → 1GB	服务短暂中断
减少Puma Workers	12GB → 6GB	可能影响高并发
内存限制	避免泄漏	需监控OOM

最终内存占用：从 95%+ 降至 30%~40%（Puma + Sidekiq + PostgreSQL）。

6. 总结

6.1 关键步骤

排查：free -h + ps aux --sort=-%mem
分析：Puma Worker内存泄漏是主因。
解决：
- 紧急重启Puma + 创建Swap。
- 长期优化：限制Worker数量/内存 + 自动重启。

6.2 最佳实践

定期重启Puma（如每日凌晨）。
启用内存监控（Prometheus + Grafana）。
合理配置Swap（至少4GB）。

7. 附录

7.1 常用命令

命令	用途
sudo gitlab-ctl tail	查看GitLab日志
sudo gitlab-rake gitlab:memory	检查内存使用
htop	交互式进程监控

7.2 参考文档

通过本次实战，我们不仅解决了内存问题，还建立了长期稳定的GitLab运行策略。如果你遇到类似问题，欢迎参考本文操作！ 🚀

本文参与腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。

原始发表：2025-11-12，如有侵权请联系 cloudcommunity@tencent.com 删除

内存

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

登录后参与评论

0 条评论

热度

GitLab内存占用过高排查与优化实战：从95%到稳定运行的完整指南

GitLab内存占用过高排查与优化实战：从95%到稳定运行的完整指南

《GitLab内存占用过高排查与优化实战：从95%到稳定运行的完整指南》

引言

1. 问题现象

2. 初步排查

2.1 检查系统内存

2.2 查看高内存进程

3. 问题分析

3.1 Puma内存泄漏

3.2 无Swap空间

3.3 Sidekiq和PostgreSQL

4. 解决方案

4.1 紧急措施

(1) 重启Puma释放内存

(2) 创建Swap空间

4.2 长期优化

(1) 调整Puma配置

(2) 优化Sidekiq

(3) 监控与自动化

5. 效果验证

6. 总结

6.1 关键步骤

6.2 最佳实践

7. 附录

7.1 常用命令

7.2 参考文档

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐