17

Gitlab 6.0 was released yesterday. I am curious to know why they switched to Unicorn from Puma. Versions prior to 5 were using Unicorn. I thought switch to Puma was for the better.

Is there a technical reason for this switch?

Litmus
  • 10,558
  • 6
  • 29
  • 44

2 Answers2

30

Update April 2020, GitLab 12.10:

Puma will become the default application server

GitLab will be switching default application servers from Unicorn to Puma in 13.0.

And with GitLab 13.0 (May 2020):

Reduced memory consumption of GitLab with Puma

Read the last sections below.

Original answer 2013

The commit 3bc484587 offers some clues from Mathieu 'OtaK' Amiot:

We switched from Puma in GitLab 5.4 to unicorn in GitLab 6.0.

why switch back to Unicorn again?

Puma caused 100% CPU and greater memory leaks when running mult-ithreaded on systems with many concurrent users.
That's because people used MRI. You MUST use JRuby or Rubynius when using Puma. Or else the world breaks apart.

Mathieu adds in the comments:

Yes, Unicorn is better (but more memory-eager) on MRI setups.
Puma is better on Rubinius & JRuby, that's all.

They can't force people to use other implementations of the Ruby Runtime, so they just fell back to the best setup for most setups :) –

Light controversy ensues around:

Puma's multithreading works just fine with MRI.
I say this as one of the authors behind Ruby Enterprise Edition, so I know Ruby's threading system inside-out.
Evan Phoenix, Puma's author, has also stated that using Puma with MRI works just fine.

If there are issues then they are likely in Gitlab's code.

That being said, in Apr. 2020, Puma is now available as an alternative web server to Unicorn with GitLab 12.9
(mentioned by mbomb007 in the comments)

Mathieu 'OtaK' Amiot comments:

Passenger is not as stable as most people think. A nginx + Unicorn is more stable IMHO. –

Hongli answers:

We have lots and lots of large users using Phusion Passenger, both open source and Enterprise, on a daily basis with great stability and success.
Think New York Times, 37signals, Motorola, UPS, Apple, AirBnB. Some of them even switched away from Unicorn in favor of Passenger (either open source or Enterprise)

Update August 2014: there is an article on "Running GitLab 7.1 using Puma instead of a Unicorn"

Update April 2020, GitLab 12.10:

Puma will become the default application server

GitLab will be switching default application servers from Unicorn to Puma in 13.0.
Puma is a multithreaded application server, allowing GitLab to reduce it’s memory consumption by about 40%.

A> s part of the GitLab 13.0 upgrade, users who have customized Unicorn settings will need to manually migrate these settings to Puma.
It will also be possible to remain on Unicorn, by disabling Puma and re-enabling Unicorn until Unicorn support is removed in a future release.

This is thanks to Dmitry Chepurovskiy, who has made a major contribution adding the Puma web server to the GitLab unicorn Helm chart (soon to be the webservice chart).

This work provides users of the GitLab Helm chart with the option to use Puma instead of Unicorn.
In testing, we have observed a 40% reduction in memory usage when using Puma as the web server.

See Epic.

With GitLab 13.0 (May 2020):

Reduced memory consumption of GitLab with Puma

Puma is now the default web application server for both the Omnibus-based and Helm-based installations. Puma reduces the memory footprint of GitLab by about 40% compared to Unicorn, increasing the efficiency of GitLab and potentially saving costs for self-hosted instances.

https://about.gitlab.com/images/13_0/puma_memory.png

Installations which have customized the number of Unicorn processes, or use a slower NFS drive, may have to adjust the default Puma configuration.
See the Important notes on upgrading and GitLab chart improvements for additional details.

See documentation and Epic.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Guess you are right. But then I couldn't find any reasoning for switch from Unicorn to Puma in [version 5.1.0](https://github.com/gitlabhq/gitlabhq/commit/1fe61284afc08796d09f1626a198a1c35f0a62aa). – Litmus Aug 23 '13 at 16:06
  • 1
    They switched to Puma because it uses less memory than Unicorn. In practice, Unicorn and Puma both have their own pros and cons, neither of them is strictly better than the other. If memory and stability is a concern then the user may also use Phusion Passenger Enterprise which uses less memory *and* is more stable ([source](https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Passenger)). – Hongli Aug 25 '13 at 11:21
  • 1
    I'm the author of this comment, `That's because people used MRI. You MUST use JRuby or Rubynius when using Puma. Or else the world breaks apart.` And yes, Unicorn is better (but more memory-eager) on MRI setups. Puma is better on Rubinius & JRuby, that's all. They can't force people to use other implementations of the Ruby Runtime, so they just fell back to the best setup for most setups :) – Mathieu Amiot Aug 27 '13 at 08:05
  • @Mathieu'OtaK'Amiot thank you for this comment. I have included it in the answer for more visibility. – VonC Aug 27 '13 at 08:24
  • Thanks @hongli for your comments. Phusion Passenger Enterprise is a commercial product, may not suite a product like Gitlab (for masses). I understand Phusion uses Gitlab, I probably should not ask this, but I would like to believe you run it on Passenger. Would you be open sourcing your Gitlab+Passenger install/upgrade recipe? – Litmus Aug 27 '13 at 11:46
  • @ShireeshJ Indeed, PPE is commercial, and for OSS projects such as Gitlab, is not suitable unless both parties are making an agreement. Moreover, **Passenger is not as stable** as most people think. A nginx + Unicorn is more stable IMHO. – Mathieu Amiot Aug 27 '13 at 13:57
  • @ShireeshJ: our recipe with Phusion Passenger Enterprise is basically the as the one we described here: http://blog.phusion.nl/2012/04/21/tutorial-setting-up-gitlab-on-debian-6/. Just replace Phusion Passenger open source with Phusion Passenger Enterprise – Hongli Aug 27 '13 at 15:54
  • @Mathieu'OtaK'Amiot: We have lots and lots of large users using Phusion Passenger, both open source and Enterprise, on a daily basis with great stability and success. Think New York Times, 37signals, Motorola, UPS, Apple, AirBnB. Some of them even switched away from Unicorn in favor of Passenger (either open source or Enterprise). Perhaps you've had bad experience with Phusion Passenger in the past? If so, could you tell us more about your problems? We'd be happy to help. We guarantee that it's stable, and if it's not for you, we'll fix it. – Hongli Aug 27 '13 at 15:56
  • 9
    As for the *"That's because people used MRI. You MUST use JRuby or Rubynius when using Puma. Or else the world breaks apart."* comment - that is false. Puma's multithreading works just fine with MRI. I say this as one of the authors behind Ruby Enterprise Edition, so I know Ruby's threading system inside-out. Evan Phoenix, Puma's author, has also stated that using Puma with MRI works just fine (https://news.ycombinator.com/item?id=5995142). If there are issues then they are likely in Gitlab's code. – Hongli Aug 27 '13 at 16:01
  • @Mathieu'OtaK'Amiot I kind of agree with Hongli with respect to stability of Passenger. We use all three - passenger, unicorn and puma. Though all are stable, I find passenger easy to manage. One of our websites www.elitmus.com runs on Passenger OSS and has an alexa rank of 13000. Thats fairly good traffic it handles. We hardly ever had problems managing traffic growth with Passenger (since version 2.0.x till now). – Litmus Aug 28 '13 at 03:29
  • @Hongli I'll give it another try then, last time I used it was with Phusion REE (http://www.rubyenterpriseedition.com/) and it was really, literally, hell. Thanks for the info :) And my bad for the bad-mouthing if I'm wrong :( – Mathieu Amiot Aug 28 '13 at 08:59
  • No worries. Please feel free to contact our support forum if you run into anything. We're always interested in making things better. – Hongli Aug 28 '13 at 16:40
  • Another update: [Puma is available in 12.9](https://docs.gitlab.com/omnibus/update/gitlab_12_changes.html#129) – mbomb007 Apr 07 '20 at 16:52
  • @mbomb007 Thank you. I have included your comment in the answer for more visibility. – VonC Apr 07 '20 at 16:59
14

GitLab B.V. CEO here, I agree with Hongli his comment that "If there are issues then they are likely in Gitlab's code.". We tried to fix them but GitLab is one of the largest open source Rails applications and the issues where hard to reproduce. So in the end we opted for the most pragmatic solution, switching back to Unicorn. We love Puma, Unicorn and Passenger and think they are all fantastic pieces of software.

Sytse Sijbrandij
  • 1,885
  • 2
  • 22
  • 20