1. 问题现场：当GitLab服务器磁盘突然爆满
那天下午3点17分，监控系统突然发出刺耳的警报声——生产环境的GitLab服务器磁盘使用率达到100%。作为运维负责人，我亲眼看着CI/CD流水线开始逐个失败，开发团队在Slack里炸开了锅。这种紧急情况如果处理不当，轻则导致数小时服务中断，重则可能引发数据丢失。
关键提示：GitLab磁盘满仓时，最先崩溃的通常是Sidekiq服务，表现为502错误和CI任务堆积。此时任何git操作都可能失败，包括关键的备份指令。
通过终端连上服务器后，我快速执行了经典的诊断三板斧：
bash复制df -h # 确认磁盘分区情况
du -sh /* 2>/dev/null # 快速扫描根目录占用
ncdu /var/opt/gitlab # 交互式分析GitLab数据目录
2. 磁盘空间杀手排查实战
2.1 罪魁祸首定位技巧
在/var/opt/gitlab目录下，这几个目录最容易成为"空间黑洞"：
| 目录路径 | 典型问题 | 检查命令 |
|---|---|---|
| /var/opt/gitlab/git-data | 仓库体积膨胀（特别是LFS文件） | sudo git count-objects -vH |
| /var/opt/gitlab/postgresql | 未清理的WAL日志或临时表 | SELECT pg_size_pretty()... |
| /var/log/gitlab | 失控的日志文件（尤其sidekiq.log） | journalctl --disk-usage |
| /var/opt/gitlab/backups | 堆积的自动备份文件 | ls -lh --sort=size |
2.2 我的真实案例复盘
那次事故最终定位到两个致命问题：
- GitLab Runner的构建缓存（/var/opt/gitlab/gitlab-ci/builds）积累了87GB旧数据
- PostgreSQL的pg_wal目录有32GB未归档的WAL日志
bash复制# 发现最大目录的快速命令组合
sudo du -Sh /var/opt/gitlab | sort -rh | head -15
3. 五分钟紧急处理方案
3.1 立即释放空间（1分钟操作）
这些命令可以快速腾出GB级空间，且相对安全：
bash复制# 清理apt缓存（可释放1-2GB）
sudo apt-get clean
# 清空系统日志轮转文件（0.5-3GB）
sudo journalctl --vacuum-size=200M
# 删除7天前的Docker容器日志（谨慎操作）
find /var/lib/docker/containers -name "*.log" -mtime +7 -delete
3.2 GitLab专项清理（3分钟操作）
bash复制# 重置CI runner缓存（危险！会中断进行中的构建）
sudo gitlab-rake cache:clear
# 清理Docker系统的无用数据
docker system prune -af
# 手动触发Git仓库压缩（需停服务）
sudo gitlab-ctl stop
sudo gitlab-rake gitlab:cleanup:repos
sudo gitlab-ctl start
3.3 数据库紧急维护（1分钟操作）
sql复制-- 连接GitLab的PostgreSQL
sudo gitlab-psql
-- 清理过期临时表
VACUUM FULL VERBOSE ANALYZE;
-- 手动触发WAL归档（如果有配置归档）
SELECT pg_switch_wal();
4. 根治方案与日常防护
4.1 预防性监控配置
在/etc/gitlab/gitlab.rb中添加这些关键监控项：
ruby复制prometheus['monitor_whitelist'] = [
'disk_used_percent{device="/dev/vda1"} > 85',
'pg_wal_files_total > 20',
'gitlab_ci_build_artifacts_size > 10737418240' # 10GB
]
4.2 自动化清理策略
创建/etc/cron.daily/gitlab_cleanup脚本：
bash复制#!/bin/bash
# 保留最近3份备份
ls -t /var/opt/gitlab/backups/* | tail -n +4 | xargs rm -f
# 自动压缩超过100MB的Git仓库
find /var/opt/gitlab/git-data -name "*.git" -type d -size +100M \
-exec git -C {} gc --prune=now \;
# 清理30天前的CI日志
find /var/log/gitlab/gitlab-ci -mtime +30 -delete
4.3 存储架构优化建议
对于大型GitLab实例，我强烈推荐这种存储分离方案：
code复制/var/opt/gitlab/git-data → 高性能SSD（仓库数据）
/var/opt/gitlab/backups → 大容量HDD（备份专用）
/var/log/gitlab → 独立日志分区（XFS格式）
5. 血泪教训：绝对不能碰的禁区
-
直接删除.git目录：会导致仓库元数据损坏，必须通过
gitlab-rake gitlab:cleanup:repos工具处理 -
粗暴清理PostgreSQL数据：误删pg_wal文件可能引发数据库崩溃，应该用
VACUUM命令 -
高峰期执行仓库压缩：git gc会消耗大量IO，务必在维护窗口期操作
那次事故后，我们建立了磁盘空间三级预警机制：
- 80%：自动触发清理脚本
- 90%：邮件+Slack告警
- 95%：自动暂停非关键CI任务
现在每次看到磁盘监控图表，都会想起那个惊心动魄的下午。建议所有GitLab管理员提前打印这份应急清单贴在工位上——当磁盘爆红时，每一秒都值得珍惜。