先用 docker ps 和 docker top 定位 ruby、gitaly、sidekiq 进程，重点调低 sidekiq 并发至 5 和 puma 线程至 2–3；再在 gitlab.rb 中强制限制 postgresql、redis 内存并关闭自适应，最后用 gitlab-ctl tail 查真实日志。
GitLab 在宝塔面板中启动后 CPU 占用持续 90%+，怎么快速定位是哪个进程在吃资源
宝塔面板本身不原生支持 GitLab，常见做法是通过 Docker 安装官方 gitlab/gitlab-ce 镜像，再用宝塔的「Docker 管理器」托管。但 GitLab 默认配置面向中大型部署，一上来就拉满 4 核 + 8GB 内存，小内存服务器（比如 2GB）必然卡死。
先别急着改配置，用这三步确认真实瓶颈：
- 进宝塔终端，运行
docker ps找到 GitLab 容器 ID - 执行
docker top，观察ruby、gitaly、sidekiq这几个进程的 CPU 和 RSS 占用 - 特别注意
sidekiq—— 它默认开 25 个并发 worker，哪怕没用户访问也会空转扫描任务
修改 gitlab.rb 限制 sidekiq 并发数和 puma 线程数
GitLab 的核心资源大户是 Sidekiq（后台任务队列）和 Puma（Web 服务）。它们的并发数不随物理内存自动缩放，必须手动压低。
进入容器内部修改主配置文件：
- 先停容器：
docker stop gitlab - 挂载宿主机目录映射时，确保
/var/opt/gitlab/gitlab-rails/etc/gitlab.rb已映射到宿主机（如/www/wwwroot/gitlab/config/gitlab.rb） - 编辑该
gitlab.rb，添加或修改以下几行：
sidekiq['max_concurrency'] = 5
puma['worker_processes'] = 2
puma['min_threads'] = 1
puma['max_threads'] = 3
gitaly['env'] = { "GITALY_CATBOX_DISABLE" => "true" }
注意：sidekiq['max_concurrency'] = 5 是最有效的一刀——从默认 25 直接砍掉 80%，对单人或小团队完全够用；puma 线程数超过 3 在 2GB 内存下极易触发 OOM Kill。
为什么加了 swap 或升级内存后 GitLab 还是启动失败
很多用户以为“加了 2GB swap 就等于有 4GB 可用内存”，但 GitLab 的 postgresql 和 redis 组件会检查可用 RAM，不是看 total，而是看 MemAvailable（Linux 4.6+）。swap 不计入此项。
现象：容器反复重启，日志里出现 ERROR: Your system has less than 4GB of memory 或 pg_ctl: could not start server。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
解决方法只有两个，且必须同时做：
- 在
gitlab.rb中强制绕过内存检查：postgresql['shared_buffers'] = "128MB"、redis['maxmemory'] = "128MB" - 关闭 PostgreSQL 的内存自适应（否则它仍会尝试申请 1/4 物理内存）：
postgresql['effective_cache_size'] = "256MB"
改完务必执行 docker exec -it gitlab gitlab-ctl reconfigure，而不是只 restart。
宝塔 Docker 管理器里看不到 gitlab 容器日志，怎么查真实报错
宝塔的 Docker 插件日志功能经常只显示容器启停状态，不透传 GitLab 内部组件日志。真正有用的错误全在 gitlab-ctl tail 里。
进容器执行：
docker exec -it gitlab bash- 运行
gitlab-ctl tail nginx查 Web 访问异常 - 运行
gitlab-ctl tail sidekiq查定时任务卡死 - 最常用的是
gitlab-ctl tail | grep -i "error\|fail\|oom"快速过滤关键线索
别依赖宝塔界面的日志按钮——它调用的是 docker logs，而 GitLab 把各组件日志都重定向到了 /var/log/gitlab/ 下的独立文件，docker logs 基本为空。
调整并发和内存参数只是起点；GitLab 的资源敏感点藏在组件间协同逻辑里，比如 Gitaly 调用超时会触发 Sidekiq 重试风暴，一个配置没对齐，其他优化全白费。
