6 ms·

Yeah, and they've promised to work on performance for ages now with almost no improvement. I run a very small installation with only a couple of projects and s

by mh-cx 9y ago

Yeah, and they've promised to work on performance for ages now with almost no improvement. I run a very small installation with only a couple of projects and some hundred issues on a 4 GB machine. It eats up 2 GB (sigh!!!) - and often still feels extremely slow. I mean 2 Gigabytes!! What for? That's a multitude of all the data I have in the DB there. And then it's not even used for something useful like caching. Some pages take several seconds to load. As a developer that's totally unacceptable to me. Is ruby really such a mess that it's impossible to run an app with reasonable memory consumption?

foepys 9y ago
Maybe you are already committed to gitlab and its workflow but Gogs and Gitea are small and fast GitHub clones written in Go if you need something light-weight.
- Kihashi 9y ago
  I'd switch to using one of those, but my team relies on the code review of gitlab.
- stevekemp 9y ago
  Personally I run gitbucket, which is a small and self-contained java-based "github alternative". There are a bunch of these small project/git-hosts, and while they're easy to manage they're less featureful than the gitlab offering. Gitlab does have some great features, such as the whole integrated CI system, built upon runners & docker. The downside is complexity, and resource-usage. I know gitlab is free, and I could install it, but the added resources and potential security issues make it a non-starter.
lloeki 9y ago
> Is ruby really such a mess that it's impossible to run an app with reasonable memory consumption? Yes. Any non-trivial Ruby app will quickly eat up 500MB, and any non-trivial Rails app will soon balloon to 1GB, with things getting worse over time due to memory fragmentation†. Since there is no parallelism your only option is to either have more unicorn workers, for which prefork and COW are hardly working to save you from duplicating memory, especially over time, or have puma threads and use JRuby, which is a memory hog of its own and often slower than MRI. There have been arguments made that developer time trumps CPU time [0] but there are some workloads and problem domains and uncontrollable events for which this works at the beginning yet later on you find having yourself painted into a corner as suddenly things are not sustainable because you just can't throw more hardware at the issue without going belly up[1]. Once the low hanging fruits have been reaped you're being challenged just to make your app behave within established parameters with diminishing returns, which I'm sure you'd rather spend on solving actual problems for your customers. At that point you might just as well spend the money on rewriting part or all of your app in a more frugal ecosystem and mindset[2]. † Switching to jemalloc may or may not help. Over here it did not. [0]: https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years-afff4a54abc7 https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-... [1]: https://twitter.com/migueldeicaza/status/950054181045440518 https://twitter.com/migueldeicaza/status/950054181045440518 [2]: https://twitter.com/lloeki/status/950079609051152384 https://twitter.com/lloeki/status/950079609051152384
- maxehmookau 9y ago
  Replace "Ruby" with any modern interpreted language and then get over it. With the price of memory so insanely cheap, why does it matter? Gitlab isn't trying to be a lean Go microservice-powered app. It's attempting to be the centre of your source control and deployment world. So 2gb usage seems reasonable to me. Any cloud provider will provide a VM that can comfortably run it for a very reasonable price.
  - kuschku 9y ago
    It’s not just 2GB – I’m running a Gitlab with essentially 2-3 users and activity every few days, and it completely maxes an entire core and uses 6GB RAM constantly.
    - slrz 9y ago
      So what does it do when it uses all that CPU despite the lack of requests coming in? Maybe you have misconfigured some periodic job like backup?
      - kuschku 9y ago
        I'm using their official helm chart, it's just idling. Sidekiq is doing nothing, the server is serving no requests - I have no idea how it manages to spend so much time on nothing.
        maxehmookau 9y ago
        The helm chart is deprecated. Use their omnibus package, it's very stable.
        kuschku 9y ago
        The helm chart "gitlab" is deprecated, the helm chart "gitlab-omnibus" is currently recommended, and the helm chart "cloud native gitlab" is going to be recommended in the near future - a GitLab employee answered me a few hours ago in this thread :) I'm using the gitlab-omnibus one.
mydigitalself 9y ago
Hi, sorry you haven't noticed any improvements. We've been chipping away at performance for the last 6 months and have made some pretty noticeable improvements in various areas of the application. For example, the average response time of an issue page has come down from 2.5s to 750ms over the last 6 months. We still have a lot to do, but we're getting there.
- sytse 9y ago
  One big thing that we would love to do is moving to a multithreaded application server https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 That would save a ton of memory but last time we tried we got burned because the ecosystem wasn't ready.
- merb 9y ago
  750ms is still a very bad value.
maxehmookau 9y ago
I'd say 2GB is a reasonable amount of memory for any application to use. Have you seen Slack recently?
YorickPeterse 9y ago
> Yeah, and they've promised to work on performance for ages now with almost > no improvement. That's simply not true, there have been a _ton_ of improvements that we made over the past 2 years. A very simplified example: A specific GitLab.com issue in December 2015 vs January 2018 (I can't seem to find what the exact URL is): 2015: http://stats.gitlab.com/1902794/2015/12 http://stats.gitlab.com/1902794/2015/12 2018: http://stats.gitlab.com/1902794/2018/01 http://stats.gitlab.com/1902794/2018/01 Apart from that you can take a look at any of the past release posts or merge requests tagged with "performance" [1][2] and you'll see that plenty of improvements have been made over time. > Is ruby really such a mess that it's impossible to run an app with > reasonable memory consumption? Ruby is not really to blame for this, instead it's mostly Rails and all the third-party libraries that we add on top that consume so much memory. [1]: CE improvements: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=performance https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope... [2]: EE improvements (some of these may be merges from CE): https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=performance https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope...
- mh-cx 9y ago
  I can only tell what I've experienced. I regularly read the release notes, especially the sections on performance. And with each upgrade I'm hoping so much that we get back to loading times below 1 second (like it was with early GitLab releases). Unfortunately this is almost never the case: Sometimes the pages load even slower. In the best case there's not much difference. Same goes for memory consumption. But I understand now that this will always be a problem with rails.
  - YorickPeterse 9y ago
    Do you have any examples on what kind of pages are loading slow? Are these issue detail pages, MR diff pages, etc? It's possible you're running into cases we're not experiencing (enough) on GitLab.com, or maybe we did but we haven't really looked into them yet.

by mh-cx 9y ago

foepys 9y ago

Maybe you are already committed to gitlab and its workflow but Gogs and Gitea are small and fast GitHub clones written in Go if you need something light-weight.

Kihashi 9y ago
I'd switch to using one of those, but my team relies on the code review of gitlab.
stevekemp 9y ago
Personally I run gitbucket, which is a small and self-contained java-based "github alternative". There are a bunch of these small project/git-hosts, and while they're easy to manage they're less featureful than the gitlab offering. Gitlab does have some great features, such as the whole integrated CI system, built upon runners & docker. The downside is complexity, and resource-usage. I know gitlab is free, and I could install it, but the added resources and potential security issues make it a non-starter.

lloeki 9y ago

> Is ruby really such a mess that it's impossible to run an app with reasonable memory consumption? Yes. Any non-trivial Ruby app will quickly eat up 500MB, and any non-trivial Rails app will soon balloon to 1GB, with things getting worse over time due to memory fragmentation†. Since there is no parallelism your only option is to either have more unicorn workers, for which prefork and COW are hardly working to save you from duplicating memory, especially over time, or have puma threads and use JRuby, which is a memory hog of its own and often slower than MRI. There have been arguments made that developer time trumps CPU time [0] but there are some workloads and problem domains and uncontrollable events for which this works at the beginning yet later on you find having yourself painted into a corner as suddenly things are not sustainable because you just can't throw more hardware at the issue without going belly up[1]. Once the low hanging fruits have been reaped you're being challenged just to make your app behave within established parameters with diminishing returns, which I'm sure you'd rather spend on solving actual problems for your customers. At that point you might just as well spend the money on rewriting part or all of your app in a more frugal ecosystem and mindset[2]. † Switching to jemalloc may or may not help. Over here it did not. [0]: https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years-afff4a54abc7 https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-... [1]: https://twitter.com/migueldeicaza/status/950054181045440518 https://twitter.com/migueldeicaza/status/950054181045440518 [2]: https://twitter.com/lloeki/status/950079609051152384 https://twitter.com/lloeki/status/950079609051152384

maxehmookau 9y ago
Replace "Ruby" with any modern interpreted language and then get over it. With the price of memory so insanely cheap, why does it matter? Gitlab isn't trying to be a lean Go microservice-powered app. It's attempting to be the centre of your source control and deployment world. So 2gb usage seems reasonable to me. Any cloud provider will provide a VM that can comfortably run it for a very reasonable price.
- kuschku 9y ago
  It’s not just 2GB – I’m running a Gitlab with essentially 2-3 users and activity every few days, and it completely maxes an entire core and uses 6GB RAM constantly.
  - slrz 9y ago
    So what does it do when it uses all that CPU despite the lack of requests coming in? Maybe you have misconfigured some periodic job like backup?
    - kuschku 9y ago
      I'm using their official helm chart, it's just idling. Sidekiq is doing nothing, the server is serving no requests - I have no idea how it manages to spend so much time on nothing.
      - maxehmookau 9y ago
        The helm chart is deprecated. Use their omnibus package, it's very stable.
        kuschku 9y ago
        The helm chart "gitlab" is deprecated, the helm chart "gitlab-omnibus" is currently recommended, and the helm chart "cloud native gitlab" is going to be recommended in the near future - a GitLab employee answered me a few hours ago in this thread :) I'm using the gitlab-omnibus one.

mydigitalself 9y ago

Hi, sorry you haven't noticed any improvements. We've been chipping away at performance for the last 6 months and have made some pretty noticeable improvements in various areas of the application. For example, the average response time of an issue page has come down from 2.5s to 750ms over the last 6 months. We still have a lot to do, but we're getting there.

sytse 9y ago
One big thing that we would love to do is moving to a multithreaded application server https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 That would save a ton of memory but last time we tried we got burned because the ecosystem wasn't ready.
merb 9y ago
750ms is still a very bad value.

maxehmookau 9y ago

I'd say 2GB is a reasonable amount of memory for any application to use. Have you seen Slack recently?

YorickPeterse 9y ago

> Yeah, and they've promised to work on performance for ages now with almost > no improvement. That's simply not true, there have been a _ton_ of improvements that we made over the past 2 years. A very simplified example: A specific GitLab.com issue in December 2015 vs January 2018 (I can't seem to find what the exact URL is): 2015: http://stats.gitlab.com/1902794/2015/12 http://stats.gitlab.com/1902794/2015/12 2018: http://stats.gitlab.com/1902794/2018/01 http://stats.gitlab.com/1902794/2018/01 Apart from that you can take a look at any of the past release posts or merge requests tagged with "performance" [1][2] and you'll see that plenty of improvements have been made over time. > Is ruby really such a mess that it's impossible to run an app with > reasonable memory consumption? Ruby is not really to blame for this, instead it's mostly Rails and all the third-party libraries that we add on top that consume so much memory. [1]: CE improvements: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=performance https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope... [2]: EE improvements (some of these may be merges from CE): https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=performance https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope...

mh-cx 9y ago
I can only tell what I've experienced. I regularly read the release notes, especially the sections on performance. And with each upgrade I'm hoping so much that we get back to loading times below 1 second (like it was with early GitLab releases). Unfortunately this is almost never the case: Sometimes the pages load even slower. In the best case there's not much difference. Same goes for memory consumption. But I understand now that this will always be a problem with rails.
- YorickPeterse 9y ago
  Do you have any examples on what kind of pages are loading slow? Are these issue detail pages, MR diff pages, etc? It's possible you're running into cases we're not experiencing (enough) on GitLab.com, or maybe we did but we haven't really looked into them yet.