2020年4月更新,GitLab 12.10:
Puma将成为默认的应用服务器
GitLab将在13.0中将默认的应用服务器从Unicorn切换到Puma。
而且在GitLab 13.0(2020年5月)中:
使用Puma减少GitLab的内存消耗
请阅读下面的最后几节。
2013年的原始答案
commit 3bc484587提供了一些来自Mathieu 'OtaK' Amiot的线索:
我们从GitLab 5.4中的Puma切换到GitLab 6.0中的unicorn。
为什么要再次切换回Unicorn呢?
在具有许多并发用户的系统上,使用多线程运行Puma会导致100%的CPU使用率和更大的内存泄漏。
这是因为人们使用了MRI。当使用Puma时,必须使用JRuby或Rubynius,否则世界将分崩离析。
Mathieu 在评论中补充道:
是的,Unicorn在MRI设置上更好(但需要更多内存)。Puma在Rubinius和JRuby上更好,仅此而已。他们不能强迫人们使用其他Ruby运行时实现,因此他们只是回到了大多数设置中最好的设置 :) -轻微争议围绕:
Puma的多线程在MRI中运行得非常好。
我是Ruby Enterprise Edition背后的作者之一,所以我深知Ruby的线程系统。
Evan Phoenix,Puma的作者,也已经表示使用Puma与MRI一起使用完全没有问题。如果存在问题,则很可能是Gitlab代码中存在问题。
话虽如此,2020年4月,Puma现在可以作为GitLab 12.9中替代Unicorn的Web服务器
(由mbomb007在评论中提到)
2014年8月更新:有一篇关于“使用Puma而不是Unicorn运行GitLab 7.1的文章”。
2020年4月更新,GitLab 12.10:
Puma将成为默认的应用服务器
GitLab将在13.0中将默认应用服务器从Unicorn切换到Puma。
Puma是一个多线程的应用服务器,使得GitLab可以将其内存消耗减少约40%。
作为GitLab 13.0升级的一部分,定制了Unicorn设置的用户需要手动将这些设置迁移到Puma。
也可能继续使用Unicorn,通过禁用Puma并重新启用Unicorn,直到在未来版本中删除Unicorn支持。
这要归功于Dmitry Chepurovskiy,他为GitLab unicorn
Helm chart(即将成为webservice chart)添加了Puma Web服务器做出了重大贡献。
安装了自定义的Unicorn进程数量或使用较慢的NFS驱动器的安装程序可能需要调整默认的Puma配置。使用Puma减少GitLab的内存消耗
Puma现在是基于Omnibus和Helm的安装的默认Web应用程序服务器。与Unicorn相比,Puma将GitLab的内存占用减少约40%,提高了GitLab的效率,并可能为自托管实例节省成本。
我是GitLab B.V.的CEO,我同意洪力所说的评论:“如果有问题,那么它们可能存在于GitLab的代码中。”我们尝试着修复了这些问题,但GitLab是最大的开源Rails应用程序之一,这些问题很难重现。所以最终我们选择了最实用的解决方案,回到了Unicorn。我们喜欢Puma、Unicorn和Passenger,认为它们都是非常棒的软件。