5 ms·

"Ruby was optimized for the developer, not for running it in production," says Sid. "For the things that get hit a lot and have to be very performant or that, f

"Ruby was optimized for the developer, not for running it in production," says Sid. "For the things that get hit a lot and have to be very performant or that, for example, have to wait very long on a system IO, we rewrite those in Go … We are still trying to make GitLab use less memory" Honestly, I think that Go is beginning to be where Rails was few years ago, and lots of developer friends want to hop on the Go train because everybody is doing the same. In the same time, I'm thinking about switching to Gitea or Gogs + Drone.io, because Gitlab takes just too.damn.much.memory ! Seriously, 8GB RAM to even just begin with ? (Because yes, 4GB RAM + 4GB Swap is not viable). Even my biggest website is not consuming as much. So if I could suggest something, it would be a global rewrite in Go or something like that, to lower the requirements, not just one or two parts (excuse me, microservices ;)). Just my 2 cents

rapind 8y ago
Or Elixir, or Rust, or Node. Having spent time with all of these options, Rails is still really really good for a lot of use cases. Go comes nowhere near Ruby's readability for me (but I like the lack of surprise). Personally I'd love something typed, performant, and as readable as Ruby with a convention focused platform like Rails. Elixir + Phoenix is probably the closest I can find, but not a perfect fit. Maybe close enough though.
- dmlittle 8y ago
  FWIW Elixir isn't necessarily lightweight. Memory will stay pretty flat (even during high workloads) but it's not lightweight.
- Legogris 8y ago
  If we're talking memory usage, I don't think Node is necessarily a significant improvement over Ruby.
- anonyfox 8y ago
  Crystal it is. Combined with the amber framework, porting the Ruby Code should be straightforward. Yes stuff isnt even 1.0 yet, but I would seriously bet on it right now.
- hazz99 8y ago
  Is there a benefit learning Elixir over Erlang? I've working a little bit with Erlang, and I've wondered if its worth the jump.
  - knrz 8y ago
    Completely! With convention and macros, it's a whole new language.
- jamescostian 8y ago
  > Go comes nowhere near Ruby's readability for me I am not fluent in either, and I'm not looking to change that, but I have read code in both. I feel the exact opposite way, and I'm not trying to start a war or anything, but I was wondering if you'd be open to talking about what things in Go you find hard to read (and what things in Ruby you find very easy to read). Or is this about libraries (are Go libraries providing lower-level APIs than Ruby ones?)? Or have you read/written a lot more code in Ruby than Go?
  - hazz99 8y ago
    I agree - Go has issues, but they're not related to readability. Perhaps if you include "familiarity with the standard interfaces" (like using io.Reader) which is different to other languages, and took a while for me to get used to.
sytse 8y ago
GitLab is using a lot of memory for various reasons, all of the big ones (like adding multi-threading which I proposed 3 years ago https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 ) can be solved without a rewrite. I've failed to make this a priority within the company. We had people work on it for some time but the day to day of shipping features, keeping GitLab secure, and other tasks took over. I'll advocate for a dedicated performance team to solve this. Until that team is formed people like Stan are making steady progress https://news.ycombinator.com/item?id=18973499 https://news.ycombinator.com/item?id=18973499
- yannovitch 8y ago
  Thanks, VERY much appreciated !
stanhu 8y ago
I agree that memory requirements are too high, but I think there is a lot of room for improvement without a complete rewrite, which would be very costly. Also keep in mind that a standalone GitLab instance ships with all batteries included: PostgreSQL, Redis, etc., all of which add to the memory requirements. That being said, we are certainly looking at moving performance-critical functions into Go. See the GitLab Workhorse and Gitaly projects as examples. There are two major ways to look at application memory usage: baseline and runtime usage. Most people pay attention to the first because that's what you see when you first deploy GitLab. However, runtime usage is just as important because a running instance could gobble up gigabytes of RAM. Baseline memory: We've made some recent progress in reducing baseline memory usage (e.g. cutting 80-100 MB per Unicorn process in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21008 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21008). However, our Unicorn workers dominate most of the memory usage, and you can see more analysis of where our memory is going in https://gitlab.com/gitlab-org/gitlab-ce/issues/49702 https://gitlab.com/gitlab-org/gitlab-ce/issues/49702. https://brandur.org/ruby-memory https://brandur.org/ruby-memory is probably the best explanation I've seen why RAM usage in Unicorn processes often rises and doesn't come down. However, we can reduce baseline usage in a number of ways: * Removing dependencies from the main application * Reducing any unnecessary allocations at startup * Moving to a multi-threaded application server (we've shipped Puma in experimental mode in https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/2801 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/...) * Improving Rails memory usage (e.g. ActiveRecord optimizations in https://github.com/rails/rails/pull/34711 https://github.com/rails/rails/pull/34711) * Improving the Ruby interpreter (e.g. helping ship a compacting garbage collector, see https://gitlab.com/gitlab-org/gitlab-ce/issues/54555 https://gitlab.com/gitlab-org/gitlab-ce/issues/54555). Runtime memory: Most of our runtime memory problems are often due to memory bloat or unoptimized code paths. For example, we put big dent in some of the most egregious background jobs over the last few months. For example, a change in our merge request processing in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22725#note_115286855 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22725... lowered 95% of our runtime usage by gigabytes. Switching to a faster XML processor in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23136 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23136 also dropped memory usage in another background job. Obviously we're still far from where we should be, but we're making progress. If you or know anyone else who might be excited to help us, please let us know! https://about.gitlab.com/jobs/ https://about.gitlab.com/jobs/ Thanks for your feedback.
atomi 8y ago
Yes on Gogs + Drone.

rapind 8y ago

Or Elixir, or Rust, or Node. Having spent time with all of these options, Rails is still really really good for a lot of use cases. Go comes nowhere near Ruby's readability for me (but I like the lack of surprise). Personally I'd love something typed, performant, and as readable as Ruby with a convention focused platform like Rails. Elixir + Phoenix is probably the closest I can find, but not a perfect fit. Maybe close enough though.

dmlittle 8y ago
FWIW Elixir isn't necessarily lightweight. Memory will stay pretty flat (even during high workloads) but it's not lightweight.
Legogris 8y ago
If we're talking memory usage, I don't think Node is necessarily a significant improvement over Ruby.
anonyfox 8y ago
Crystal it is. Combined with the amber framework, porting the Ruby Code should be straightforward. Yes stuff isnt even 1.0 yet, but I would seriously bet on it right now.
hazz99 8y ago
Is there a benefit learning Elixir over Erlang? I've working a little bit with Erlang, and I've wondered if its worth the jump.
- knrz 8y ago
  Completely! With convention and macros, it's a whole new language.
jamescostian 8y ago
> Go comes nowhere near Ruby's readability for me I am not fluent in either, and I'm not looking to change that, but I have read code in both. I feel the exact opposite way, and I'm not trying to start a war or anything, but I was wondering if you'd be open to talking about what things in Go you find hard to read (and what things in Ruby you find very easy to read). Or is this about libraries (are Go libraries providing lower-level APIs than Ruby ones?)? Or have you read/written a lot more code in Ruby than Go?
- hazz99 8y ago
  I agree - Go has issues, but they're not related to readability. Perhaps if you include "familiarity with the standard interfaces" (like using io.Reader) which is different to other languages, and took a while for me to get used to.

sytse 8y ago

GitLab is using a lot of memory for various reasons, all of the big ones (like adding multi-threading which I proposed 3 years ago https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 ) can be solved without a rewrite. I've failed to make this a priority within the company. We had people work on it for some time but the day to day of shipping features, keeping GitLab secure, and other tasks took over. I'll advocate for a dedicated performance team to solve this. Until that team is formed people like Stan are making steady progress https://news.ycombinator.com/item?id=18973499 https://news.ycombinator.com/item?id=18973499

yannovitch 8y ago
Thanks, VERY much appreciated !

stanhu 8y ago

I agree that memory requirements are too high, but I think there is a lot of room for improvement without a complete rewrite, which would be very costly. Also keep in mind that a standalone GitLab instance ships with all batteries included: PostgreSQL, Redis, etc., all of which add to the memory requirements. That being said, we are certainly looking at moving performance-critical functions into Go. See the GitLab Workhorse and Gitaly projects as examples. There are two major ways to look at application memory usage: baseline and runtime usage. Most people pay attention to the first because that's what you see when you first deploy GitLab. However, runtime usage is just as important because a running instance could gobble up gigabytes of RAM. Baseline memory: We've made some recent progress in reducing baseline memory usage (e.g. cutting 80-100 MB per Unicorn process in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21008 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21008). However, our Unicorn workers dominate most of the memory usage, and you can see more analysis of where our memory is going in https://gitlab.com/gitlab-org/gitlab-ce/issues/49702 https://gitlab.com/gitlab-org/gitlab-ce/issues/49702. https://brandur.org/ruby-memory https://brandur.org/ruby-memory is probably the best explanation I've seen why RAM usage in Unicorn processes often rises and doesn't come down. However, we can reduce baseline usage in a number of ways: * Removing dependencies from the main application * Reducing any unnecessary allocations at startup * Moving to a multi-threaded application server (we've shipped Puma in experimental mode in https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/2801 https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/...) * Improving Rails memory usage (e.g. ActiveRecord optimizations in https://github.com/rails/rails/pull/34711 https://github.com/rails/rails/pull/34711) * Improving the Ruby interpreter (e.g. helping ship a compacting garbage collector, see https://gitlab.com/gitlab-org/gitlab-ce/issues/54555 https://gitlab.com/gitlab-org/gitlab-ce/issues/54555). Runtime memory: Most of our runtime memory problems are often due to memory bloat or unoptimized code paths. For example, we put big dent in some of the most egregious background jobs over the last few months. For example, a change in our merge request processing in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22725#note_115286855 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22725... lowered 95% of our runtime usage by gigabytes. Switching to a faster XML processor in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23136 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23136 also dropped memory usage in another background job. Obviously we're still far from where we should be, but we're making progress. If you or know anyone else who might be excited to help us, please let us know! https://about.gitlab.com/jobs/ https://about.gitlab.com/jobs/ Thanks for your feedback.

atomi 8y ago

Yes on Gogs + Drone.