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过去的，所以非常多的仓库都存在这个设置，如今只能慢慢手动关闭了，发现一个处理一个。这样的话我们继续观察后台停滞任务，基本上不会再有新增和重试了
评论