[mh-cx]

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?

[lloeki]

> 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-...

[1]: https://twitter.com/migueldeicaza/status/950054181045440518

[2]: https://twitter.com/lloeki/status/950079609051152384

[mh-cx]

Thanks. I was afraid to hear something like this.

Being a PHP developer myself it's really hard to believe that resource consumption is obviously treaded with so little priority in the rails/ruby world.

And some attitudes here like "who cares? memory/cpu is cheap nowadays" are in my opinion part of the problem. I'd say, well written software should use as little resources as possible. Probably a habit that comes from my early days on a C64 back in the 80s.

[maxehmookau]

> well written software should use as little resources as possible

It's about priorities. IMO if using as little resources as possible is priority number 1, then something is amiss.

[maxehmookau]

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]

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]

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]

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]

The helm chart is deprecated. Use their omnibus package, it's very stable.

[mydigitalself]

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]

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 That would save a ton of memory but last time we tried we got burned because the ecosystem wasn't ready.

[merb]

750ms is still a very bad value.

[foepys]

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.

[stevekemp]

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.

[Kihashi]

I'd switch to using one of those, but my team relies on the code review of gitlab.

[YorickPeterse]

    > 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

2018: 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...

[2]: EE improvements (some of these may be merges from CE): https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope...

[mh-cx]

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]

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.

[maxehmookau]

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