why did gitlab 6 switch back to 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.
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: Hongli comments:
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)
- Phusion Passenger Enterprise:
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.
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.
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.