Once upgraded to 17, members cannot push to projects for some time ranging from 30 seconds to 1 minute after they’ve been invited to the project. Previously that worked instantaneously. This is a huge annoyance.
Huge memory utilization on 17.
When we were on 13, 4 GB was enough.
Now it barely gets out of bed, with 6 GB.
4GB is absolute minimum when in relation to hardware specs and usually means “don’t expect to do much with it”. 8GB is recommended, even says so in the documentation. So if you attempt to use less, no wonder it doesn’t work. As with most software, the more you use it, the more resources are required.
1 Like
8 GB for this?
Really?
This is more than Windows 10 requires. Is Gitlab larger than W10 with all of its… innards?
And Windows 10 is just Windows 10. Compare Windows 10 to Linux desktop and Linux desktop will use far less than Windows 10. Gitlab is a complex application that contains a database, in-memory cache (redis), ruby application, web server, etc, Windows is not even comparable.
If you are going to make some sort of comparison at least find something that actually does the same thing as Gitlab. Otherwise, don’t bother with such a lame comparison as that. Pathetic.
Reference architectures are documented in Reference architectures | GitLab and can help with planning hardware upgrade cycles when the user/project/pipeline amount grows over time.
Which unused/unnecessary functions can we carve out of default vanilla install of gitlab that comes with your Debian VM?
We do not use anything than bare git push/pull/merge.
I already disabled a few dozens of integrations with all sorts of… stuff such as russkie Telegram and chicom-sounding thingie that made me feel like our source code is being automatically uploaded to Xi/Putin. That shrunk the memory footprint. What else is out there that can be disabled?
Redis occupies 6 MB
All instances of postgres combined less than 100 MB.
The 3 instances of ruby take 1 GB each.
The rest is insignificant.
First you can check and see how your status compares to mine:
root@gitlab:~# gitlab-ctl status
run: gitaly: (pid 773) 1600s; run: log: (pid 767) 1600s
run: gitlab-workhorse: (pid 764) 1600s; run: log: (pid 761) 1600s
run: logrotate: (pid 771) 1600s; run: log: (pid 757) 1600s
run: nginx: (pid 755) 1600s; run: log: (pid 754) 1600s
run: postgresql: (pid 753) 1600s; run: log: (pid 752) 1600s
run: puma: (pid 760) 1600s; run: log: (pid 756) 1600s
run: redis: (pid 775) 1600s; run: log: (pid 772) 1600s
run: sidekiq: (pid 762) 1600s; run: log: (pid 758) 1600s
if you have services that I don’t have from above, you can then disable those ones. For example:
gitlab_kas['enable'] = false
prometheus['enable'] = false
prometheus_monitoring['enable'] = false
in /etc/gitlab/gitlab.rb. Other than that:
and:
can help reduce memory consumption further. In reality though, whilst you can do it on 4GB, it works extremely slow and is just too painful (I know, I tried it personally and gave up). 8GB is what you should have memory wise to enjoy Gitlab running faster.
Nothing more than what I listed above can be disabled, therefore if you are not willing to increase your memory to 8GB (and it isn’t expensive to do so), then you should forget about using Gitlab.
1 Like
root@gitlab:~# gitlab-ctl status
run: alertmanager: (pid 609) 43647s; run: log: (pid 607) 43647s
run: gitaly: (pid 599) 43647s; run: log: (pid 592) 43647s
run: gitlab-exporter: (pid 608) 43647s; run: log: (pid 605) 43647s
run: gitlab-kas: (pid 711) 43645s; run: log: (pid 616) 43647s
run: gitlab-workhorse: (pid 597) 43647s; run: log: (pid 593) 43647s
run: logrotate: (pid 17736) 446s; run: log: (pid 590) 43647s
run: nginx: (pid 587) 43647s; run: log: (pid 584) 43647s
run: node-exporter: (pid 613) 43647s; run: log: (pid 611) 43647s
run: postgres-exporter: (pid 591) 43647s; run: log: (pid 588) 43647s
run: postgresql: (pid 602) 43647s; run: log: (pid 594) 43647s
run: prometheus: (pid 603) 43647s; run: log: (pid 596) 43647s
run: puma: (pid 598) 43647s; run: log: (pid 589) 43647s
run: redis: (pid 601) 43647s; run: log: (pid 600) 43647s
run: redis-exporter: (pid 610) 43647s; run: log: (pid 604) 43647s
run: sidekiq: (pid 586) 43647s; run: log: (pid 585) 43647s
So much is on by default.
Now, this is weird:
##! Enable GitLab KAS
# gitlab_kas['enable'] = true
# prometheus['enable'] = true
Are they enabled by default? Should they be set to false?
There is no line to enable/disable node-exporter, postgres-exporter, or redis-exporter.
Are you using memory-leaky ruby 3.3 for GL 17 or the still good 3.2?
I use what is included in the Gitlab omnibus package:
/opt/gitlab/embedded/bin/ruby -v
ruby 3.1.5p253 (2024-04-023 revision 1945f8dc0e) [x86_64-linux]
and that is for Gitlab 17.2.1. You don’t need Ruby 3.2 or 3.3 installed, since the Gitlab package includes everything what is needed. And when Gitlab packages are upgraded, so are their dependencies. You would only need to install dependencies manually if you are building Gitlab from source.
1 Like
Followed the links and got this error:
Running handlers:
[2024-07-30T10:28:31-04:00] ERROR: Running exception handlers
There was an error running gitlab-ctl reconfigure:
Removed configurations found in gitlab.rb. Aborting reconfigure.
Removals:
* sidekiq['max_concurrency'] has been deprecated since 16.9 and was removed in 17.0. Starting with GitLab 17.0, `sidekiq['max_concurrency']` will be removed. Please follow https://docs.gitlab.com/ee/administration/sidekiq/extra_sidekiq_processes.html#manage-thread-counts-explicitly to use `sidekiq['concurrency']` instead.
And from the error that you posted, it also gives you the solution.
1 Like
Once all that was turned off, it runs on 5 GB with 1.3 available.
Those things probably should be opt-in OOB.