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

个人名片

🎓作者简介：java领域优质创作者
🌐个人主页：码农阿豪
📞工作室：新空间代码工作室（提供各种软件服务)
💌个人邮箱：[2435024119@qq.com]
📱个人微信：15279484656
🌐个人导航网站：www.forff.top
💡座右铭：总有人要赢。为什么不能是我呢？

• 专栏导航：

码农阿豪系列专栏导航
面试专栏：收集了java相关高频面试题，面试实战总结🍻🎉🖥️
Spring5系列专栏：整理了Spring5重要知识点与实战演练，有案例可直接使用🚀🔧💻
Redis专栏：Redis从零到一学习分享，经验总结，案例实战💐📝💡
全栈系列专栏：海纳百川有容乃大，可能你想要的东西里面都有🤸🌱🚀

目录

• 《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 参考文档

《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 关键步骤

1. 排查：free -h + ps aux --sort=-%mem
2. 分析：Puma Worker内存泄漏是主因。
3. 解决：
   • 紧急重启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 Puma调优指南
• Linux Swap配置

---

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