Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Degraded performance on GitLab.com

gitlab.com

Post reply on HN
Print view View original

11–20 of 46 posts

Re: Degraded performance on GitLab.com

#11

Post by samcday »

I recently started a new position at a company that is using Gitlab. In the last month I've seen a lot of degraded performance and service outages (especially in Gitlab CI).

And then I see stuff like this that makes me scratch my head: https://about.gitlab.com/product/service-desk/

If anyone at Gitlab is reading this ... please, please slow down on chasing new markets + features and just make the stuff you already have work properly, and fill in the missing pieces. Example: https://gitlab.com/gitlab-org/gitlab-ce/issues/63880

Re: Degraded performance on GitLab.com

#14

Post by rococode »

mr__y wrote: post #10
umvi wrote: post #4

GitLab is best (imo) as a private instance; we haven't had any issues with it after using it for 3 years now

exactly my experience. Assuming that a powerful enough server is available to do that. Our first attempt to run gitlab on some small cheap VPS (2 cores, 4 gigs of ram) was a total disaster.

What server specs are working well for you?

Re: Degraded performance on GitLab.com

#15

Post by tylfin »

samcday wrote: post #11

I recently started a new position at a company that is using Gitlab. In the last month I've seen a lot of degraded performance and service outages (especially in Gitlab CI). And then I see stuff like this that makes me scratch my head: https://about.gitlab.com/product/service-desk/ If anyone at Gitlab is reading this ... please, please slow down on chasing new markets + features and just make the stuff you already ha…

> please, please slow down on chasing new markets + features and just make the stuff you already have work properly

I really agree with this. I was working at a company where we were exploring switching from Github enterprise to Gitlab for the K8s integrations, the docker registry, and the CI features.

Following the helm chart installation instructions was a nightmare because we were on-prem w/ a custom cluster. There were a lot of assumptions we had to find workarounds for (e.g. we used an f5 integration to manage our ingresses and performed SSL termination elsewhere so the nginx thing was awful).

The other terrifying bit was the number of services / pods that got brought up with the installation. If I have to monitor my team's services, I really don't want to monitor the health of: NGINX, Postgres, Redis, Minio, Registry, GitLab/sidekiq, GitLab/gitlab-shell, GitLab/gitaly, GitLab/unicorn, and GitLab/migrations.

When it comes to on-prem or self-hosted software I actually prefer running a monolithic application that worst-case I can just bounce or reboot the server.

Slow down, simplify things, and improve the user experience. Gitlab already has enough features to be competitive for a while with the Github + marketplace model.

Re: Degraded performance on GitLab.com

#16

Post by dijit »

rococode wrote: post #14
mr__y wrote: post #10

Earlier quoted context omitted.

exactly my experience. Assuming that a powerful enough server is available to do that. Our first attempt to run gitlab on some small cheap VPS (2 cores, 4 gigs of ram) was a total disaster.

What server specs are working well for you?

Not OP but I have a number of gitlab instances:

For 5 users we use 18G/4vCPU. For 20 users we use 32G/8vCPU

I keep asking to lower the footprint but the gitlab is the very definition of feature creep. And that comes at the cost of optimisation.

Re: Degraded performance on GitLab.com

#18

Post by swozey »

umvi wrote: post #4

GitLab is best (imo) as a private instance; we haven't had any issues with it after using it for 3 years now

There have been a number of updates in the last 3 years that would have completely broken or caused 500 errors on your Gitlab instance if you immediately updated it prior to a hotfix being released. If you didn't encounter these I would be shocked or you're keeping off bleeding edge releases (smart). I've managed private gitlabs for 4-5 years. I've submitted ~5-10 tickets regarding various things breaking (gitlab-runner, pages 500ing after an upgrade, etc).

If you give each update a few weeks/month and pay attention to the comments on each release blog you'll save yourself quite a bit of headaches.

Re: Degraded performance on GitLab.com

#19

Post by mr__y »

rococode wrote: post #14
mr__y wrote: post #10

Earlier quoted context omitted.

exactly my experience. Assuming that a powerful enough server is available to do that. Our first attempt to run gitlab on some small cheap VPS (2 cores, 4 gigs of ram) was a total disaster.

What server specs are working well for you?

quad core with 16 gigs of ram for a team of 4 people. Most likely 8gb of ram would be sufficient for us but the risk of decreasing our productivity is not worth the insignificant difference in price of 8GB vs 16GB VPS monthly fee.

Re: Degraded performance on GitLab.com

#20

Post by citruspi »

tylfin wrote: post #15
samcday wrote: post #11

I recently started a new position at a company that is using Gitlab. In the last month I've seen a lot of degraded performance and service outages (especially in Gitlab CI). And then I see stuff like this that makes me scratch my head: https://about.gitlab.com/product/service-desk/ If anyone at Gitlab is reading this ... please, please slow down on chasing new markets + features and just make the stuff you already ha…

> please, please slow down on chasing new markets + features and just make the stuff you already have work properly I really agree with this. I was working at a company where we were exploring switching from Github enterprise to Gitlab for the K8s integrations, the docker registry, and the CI features. Following the helm chart installation instructions was a nightmare because we were on-prem w/ a custom cluster. Ther…

> When it comes to on-prem or self-hosted software I actually prefer running a monolithic application that worst-case I can just bounce or reboot the server.

So why not just skip the helm chart and install the omnibus package on a dedicated server? If you want you can even disable stuff like the omnibus Postgres/Redis/etc and manage those yourself elsewhere.

That's what I do - run the omnibus package sans fancy helm chart - and it works out pretty well. Granted it does require a fair bit of RAM to run smoothly.

> Slow down, simplify things, and improve the user experience. Gitlab already has enough features to be competitive for a while with the Github + marketplace model.

Completely agree with this and what the parent said - I think this is part of why running Gitlab seems to require an ever increasing amount of compute resources :(

Post reply on HN