如何在GitLab环境下优化Ruby进程内存占用？（2GB内存机器）

兄弟，看你这top输出，几个Ruby进程在2GB内存的机器上吃掉了快70%的内存，确实顶不住！结合GitLab的使用场景，给你整理了几个实打实的优化方案，亲测有效：

GitLab默认用Unicorn或者Puma作为Ruby的应用服务器，这俩的worker数量和内存限制是内存占用的关键：

• 缩减Worker数量+设置内存上限：2GB内存的机器，Unicorn的worker数建议设为2-3个（默认可能更多），同时给每个worker加内存限制，防止单个进程无限制膨胀。编辑/etc/gitlab/gitlab.rb：

  # Unicorn配置
  unicorn['worker_processes'] = 2
  unicorn['worker_memory_limit_min'] = "100M"
  unicorn['worker_memory_limit_max'] = "250M"
  
  # 如果是Puma（新版GitLab默认用Puma），则用下面的配置
  puma['worker_processes'] = 2
  puma['per_worker_max_memory_mb'] = 250
  

• 砍掉没用的GitLab组件：很多默认开启的组件你大概率用不上，比如Registry、Pages、Mattermost，甚至Prometheus监控，关掉它们能直接减少Ruby进程（以及其他配套进程）的负载。在gitlab.rb里添加：

  gitlab_registry['enable'] = false
  gitlab_pages['enable'] = false
  mattermost['enable'] = false
  prometheus['enable'] = false
  

Ruby的GC默认参数对小内存机器不太友好，手动调优能让内存回收更及时：

• 自定义GC环境变量：在gitlab.rb里给Unicorn/Puma添加GC参数，让Ruby更早触发垃圾回收，避免内存堆积：

  unicorn['env'] = {
    'RUBY_GC_HEAP_INIT_SLOTS' => '100000',
    'RUBY_GC_HEAP_FREE_SLOTS' => '40000',
    'RUBY_GC_MALLOC_LIMIT' => '50000000',
    'RUBY_GC_HEAP_GROWTH_FACTOR' => '1.2'
  }
  # Puma的话替换成puma['env']
  

• 可选：切换到JRuby：JRuby的内存管理比标准MRI Ruby更高效，支持真正的多线程，能减少worker数量（甚至只用1个worker）。如果愿意折腾，可以在gitlab.rb里指定：

  gitlab_ruby['ruby_version'] = 'jruby'
  

  注意切换后需要重新配置GitLab，适合对性能和内存都有要求的场景。

2GB内存实在紧张，系统层面的小调整能帮你撑住：

• 创建Swap分区应急：搞个1-2GB的swap分区，当物理内存不够时，系统会用磁盘临时顶一下（虽然性能会降，但总比OOM强）。执行以下命令：

  sudo fallocate -l 2G /swapfile
  sudo chmod 600 /swapfile
  sudo mkswap /swapfile
  sudo swapon /swapfile
  

  然后把/swapfile none swap defaults 0 0加到/etc/fstab里，重启后自动生效。
• 调整OOM Killer策略：Linux的OOM Killer会在内存耗尽时杀进程，默认可能先杀MySQL这种核心服务，我们可以让它优先杀Ruby worker（因为worker可以自动重启）。编辑/etc/sysctl.conf添加：

  vm.oom_score_adj = -1000  # 给mysqld降低被杀优先级
  

  同时在gitlab.rb里给Ruby进程提高优先级：

  unicorn['oom_score_adj'] = 1000
  # Puma的话是puma['oom_score_adj'] = 1000
  

改完所有配置后，执行sudo gitlab-ctl reconfigure让配置生效，然后用top或者htop盯着内存变化，看看Ruby进程的RES内存有没有降下来。同时用gitlab-ctl status检查所有组件是否正常，确保没因为禁用组件导致功能崩了。

内容的提问来源于stack exchange，提问作者ebyte