gitlab宕机问题、资源不足、OOM、cpu过高 现象 gitlab多次宕机，页面由nginx显示502 第一次排查 通过排查 messages 和 dmesg 再配合监控，发现存在 OOM 情况，操作系统内存、SWAP使用殆尽，其中 oom-kill 的是 puma 进程 以及 页面 502 所以合理怀疑是web宕机 解决办法：每天凌晨重启gitlab，并且修改 `/etc/gitlab/gitlab.rb` 修改 puma 单进程为集群模式，增加每个工作节点的内存 第二次排查 第二次宕机，发现内存使用率并没有达到较高的水平，且仍然有剩余内存，messsages 和 dmesg 没有任何关于 OOM 的信息，所以这次应该不是内存不足导致的宕机，但观察机器其他性能指标，发现其CPU较高，通过nginx的日志，发现在较高的时刻，以及研发反馈的时候，其日志内有大量的请求以及大量的 502 错误 继续排查，发现客户端在此时有大量的请求，大概 12 秒有 2700 个请求，并且此时其他请求非常少，说明此请求由同一个客户端发送出来 "http_user_agent":"vs-code-gitlab-workflow/5.18.1 VSCode/1.95.1 Node.js/20.18.0 (win32; x64)" 通过此 user-agent 确定是 vscode 的插件，同时发现了gitlab文档内关于puma cpu 达到 100%会出现502的问题，综合考虑猜测是vscode某插件请求量太高导致高负载异常，以下是参考文档： https://docs.gitlab.com/17.4/ee/administration/operations/puma.html#502-gateway-timeout-after-puma-spins-at-100-cpu 发现其他用户也存在请求较大而CPU过高的问题，参考文档 https://forum.gitlab.com/t/high-cpu-usage-by-puma-workers/115315/5 解决办法： 既然确定了高并发导致 puma 过载，无法继续响应请求，所以找到了用户、并发较高的请求，以及插件： /api/v4/projects/ /api/v4/version /api/graphql 先判断了几个请求的类型，发现 version 是 GET 请求，并且获取的内容是 gitlab 版本信息，所以可以考虑把此请求内容缓存，减轻 puma 的部分压力，另外两个请求都是 POST，并且内容不固定，基本都是 gitlab 支持的查询请求，无法作为缓存 跟vscode用户进行了沟通，确定该插件无法通过配置来限制并发量，所以仍然只能通过服务端来解决，计划通过限流来解决，限流的思路一共有几种： 通过客户端ip+uri 通过 user-agent+uri 通过 客户端会话+uri 最后通过权衡选择了方案3，原因是客户端ip基本都是公司出口，这里难以区分，再就是 user-agent 也可能存在多数人使用插件的情况，不能几个人一访问就直接到达并发量，所以最后计划通过用户的会话来判断单个用户是否达到限流 nginx限流 nginx限流方案配置： 修改配置文件 nginx.conf map $cookie__gitlab_session $limit_req_key { default default; "" default; ~.+ $cookie__gitlab_session; } proxy_cache_path /data/nginx/nginx_cache levels=1:2 keys_zone=cache_zone:64m max_size=100m inactive=60m; limit_req_zone $limit_req_key zone=api_zone_v1:64m rate=15r/s; limit_req_zone $limit_req_key zone=api_zone_v2:64m rate=15r/s; limit_req_zone $limit_req_key zone=api_zone_test:64m rate=3r/s; 修改配置文件 gitlab.conf 其中对POST接口做了限流，对于 GET 请求的 version 做了缓存 location /api/graphql { limit_req zone=api_zone_v1 burst=15 nodelay; proxy_pass https://127.0.0.1:18092; } location /api/v4/projects { limit_req zone=api_zone_v2 burst=15 nodelay; proxy_pass https://127.0.0.1:18092; } location = /api/v4/version { proxy_ignore_headers Cache-Control; proxy_cache cache_zone; proxy_cache_valid 200 7d; proxy_cache_key "$uri"; proxy_pass https://127.0.0.1:18092; expires 7d; } PS. 上面配置中通过 map 拿到了请求中 cookie 的其中一个变量（可以代表不同会话），以实现不同会话的限流，如果请求中没有会话字段、或者字段内容为空，那么就会设置 default 值，这些请求会归类到一个限流中，看起来是可能存在问题，如果整体的 default 的并发较高，那么很多用户会被限制，其实不是这样的，因为这两个请求都是 POST，那么对于没有会话的请求来说，它是不合法的，必须需要会话才能够请求，所以这里是无需担心的。 gitlab优化 对于 gitlab.rb 中关于 puma 的优化配置 puma['enable'] puma['worker_timeout'] = 60 # Reduce the number of running workers to the minimum in order to reduce memory usage # 设置0关闭集群模式，实验性功能，官方还不明确推荐于生产环境 --- 20240912 目前发现设置为0只有一个进程，当内存使用过高重启会导致无法访问 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8477 // https://docs.gitlab.com/ee/administration/operations/puma.html puma['worker_processes'] = 2 puma['preload_app'] = true puma['min_threads'] = 2 puma['max_threads'] = 2 # 设置每个 worker 进程最大内存使用，如果 worker_processes 为 0，则参数失效 puma['per_worker_max_memory_mb'] = 1536 # 1GB # 上面这个参数会直接杀死进程,有可能对请求有影响,增加 preload_app 和 max_requests 参数,使得puma工作进程能够在内存不足之前优雅重启 puma['max_requests'] = 1000 puma['port'] = 8052 puma['log_level'] = 'info' puma['worker_log'] = '/var/log/gitlab/puma/puma_worker.log' 最终解决方案 以上方法对体验有影响、且高峰使用时间仍然不能很好解决，所以除了对GET请求做缓存外，增加了服务器的配置来彻底解决

gitlab日志分析工具fast-stats 0x1 问题 gitlab日志目录下 /var/log/gitlab 内容还是比较多的，在出现一些性能问题、故障去分析日志很麻烦，内容量大、多 这时我们可以借助 fast-stats 工具，来快速的分析 gitlab 日志，以下大概几个用法： ./fast-stats top /var/log/gitlab/sidekiq/current ./fast-stats top /var/log/gitlab/gitlab-rails/production_json.log ./fast-stats top /var/log/gitlab/gitlab-shell/gitlab-shell.log 0x0 参考文档 https://forum.gitlab.com/t/git-bundle-high-cpu-usage/81443/1 下载地址: https://gitlab.com/gitlab-com/support/toolbox/fast-stats

gitlab高负载高cpu使用率 0x1 问题 gitlab某个时刻非常卡，网页打开都很慢。登录后可以看到负载较高、cpu使用率较高，可以确定是cpu使用过高引起的。 继续 在 top 中排序 发现 bundle 进程使用率非常高，根据进程号查询明细，可以看到是 sidekiq 进程 0x2 分析解决 sidekiq在gitlab服务中是作为任务调度使用的，相关的内容在管理员后台 -> 监控 -> 后台任务 中。所以调整的思路是控制任务的并发以及减小任务量 办法一：减少并发 # gitlab的优化 # Reduce the number of running workers to the minimum in order to reduce memory usage puma['worker_processes'] = 2 sidekiq['max_concurrency'] = 9 # Turn off monitoring to reduce idle cpu and disk usage prometheus_monitoring['enable'] = false 通过修改 gitlab.rb 配置文件，减少最大并发数以及关闭性能监控等节省性能 方法二：关闭无效任务 本来在原图中，是可以看到有相当多的已停滞任务，查看明细会继续调度时间重试，这些任务基本上都是 email_on_push ，详情就是推送合并触发邮件，并且目的邮箱已经不存在了，所以是可以取消的，那么 email_on_push　是在哪里开启呢，通过查看gitlab页面后，发现在： 设置->集成 存在 '推送时发送电子邮件' '流水线状态电子邮件' # 进入设置关闭即可 不过这里出现了个最大的问题，此功能看起来是在某个中央仓库中早就启用，很多仓库都是从这个仓库fork过去的，所以非常多的仓库都存在这个设置，如今只能慢慢手动关闭了，发现一个处理一个。这样的话我们继续观察后台停滞任务，基本上不会再有新增和重试了

gitlab-runner/gitlab-ci的使用 0x1 优点 gitlab-runner、gitlab-ci能够主动触发任务。比如当某个分支的代码更新的时候自动触发任务，然后远程机器更新代码、编译，发布到站点。这样的话可以减少很多人工的资源更新站点。 0x2 安装部署 主要有以下步骤： 远程机器安装 gitlab-runner ，用于 gitlab 服务器指定分支提交任务后能够触发此机器 远程机器准备脚本，用于被调用后更新代码、编译、发布到站点，例如示例脚本： # 大概的步骤就是拉取指定分支代码、编译、发布到web服务器 #!/bin/bash # . /etc/profile . ~/.bash_profile set -x deploy_path="/data/www" if [ ! -d "/data/www/.git" ];then git clone git@gitlab.succez.com:product/www.git $deploy_path else cd $deploy_path git pull [ ! -d /data/www1 ] && mkdir -pv /data/www1 /usr/local/bin/npm run compile fi 在 gitlab 仓库中，代码目录下增加文件 .gitlab-ci.yml，内容示例如下: stages: - deploy deploy: stage: deploy script: - /home/gitlab-runner/bin/deploy_new only: - dev@product/www tags: - only_dev 具体参数的含义可以找到 gitlab-ci或者 gitlab-runner 文档查看，这里的意思大概是仅 dev 分支有更新才会出发编译，其他情况则不会 依次在此仓库中找到设置-> CI/CD -> Runner 找到注册地址和注册令牌，然后到远程机器上注册此仓库 到远程机器上执行命令 gitlab-runner register 然后根据提示注册到 gitlab 仓库上 回到 gitlab 仓库 runner 页面，即可看到注册上来的远程机器 gitlab-runner ，需要状态图片是绿色表示在线 至此，我们提交一个此分支的任务，即可在 CI/CD -> 流水线 中看到任务的执行了，后续也可以通过这里排查编译错误等