4 ms·

kind of wish they had kept it a little more lightweight. been running v7.10.5 as a personal repo on a small-ish sized vps. went to upgrade/migrate to a newer ve

kind of wish they had kept it a little more lightweight. been running v7.10.5 as a personal repo on a small-ish sized vps. went to upgrade/migrate to a newer version the other day and the recent versions crash out on the same host configuration. i eventually got it up and running but it was sluggish and nearly unusable. sticking with v7.10.5 for now but i will probably switch to gogs or something similar soon.

0xffff2 7y ago
Sluggish and nearly unusable describes every experience I have ever had with GitLab.
- dsumenkovic 7y ago
  Thanks for the feedback. We are working hard to improve performance and memory consumption of GitLab. We have two major projects underway, switching to Puma [1] as well as reducing the overall memory consumption of GitLab [2]. You can follow along on some of the progress we are making in each release post in the "Performance Improvements" section. For 12.2 you can see we had 58 MR's related to performance. [1] - https://docs.gitlab.com/omnibus/settings/puma.html https://docs.gitlab.com/omnibus/settings/puma.html [2] - https://about.gitlab.com/handbook/engineering/development/enablement/memory/ https://about.gitlab.com/handbook/engineering/development/en... [3] - https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=&state=merged&label_name%5B%5D=performance&milestone_title=12.2 https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=...
  - stevekemp 7y ago
    I've heard this from gitlab employees before. Every. Single. Release. For. The. Past. Two. Years. At some point it seems clear that despite statements to the contrary the speed of the instance, and the resource consumption just cannot be a concern. I'd rather the core was speedy and resource-appropriate than see additional half-working features bolted on non-stop, while bug reports languish.
    - emilycook 7y ago
      Hello! We haven't been at the capacity employee-wise to have teams dedicated to improve much in these areas, but we tripled our employee count this year and have since spun up a memory team [1] and are able to dedicate more people to performance [2]. So hopefully we won't be saying this for much longer! --- [1] (same link as #2 above) https://about.gitlab.com/handbook/engineering/development/enablement/memory/ https://about.gitlab.com/handbook/engineering/development/en... [2] https://about.gitlab.com/handbook/engineering/performance/ https://about.gitlab.com/handbook/engineering/performance/
joshlambert 7y ago
Hi - thanks for the feedback, we aren't where we want to be with performance. We are working hard to improve responsiveness and memory consumption, and have a recently started a team focused on just these aspects to accelerate the improvements. You can read more about the rationale here, including stories like yours: https://about.gitlab.com/2019/09/13/why-we-created-the-gitlab-memory-team/ https://about.gitlab.com/2019/09/13/why-we-created-the-gitla... One of the major projects the team is working on, is to switch from unicorn to puma: https://docs.gitlab.com/omnibus/settings/puma.html https://docs.gitlab.com/omnibus/settings/puma.html We are also continuing our broader effort at improving performance each release, for example in 12.2 we had 58 MR's focused on performance improvements: https://about.gitlab.com/2019/08/22/gitlab-12-2-released/#performance-improvements https://about.gitlab.com/2019/08/22/gitlab-12-2-released/#pe... Hopefully you will start to feel the impact of these investments soon.
zrail 7y ago
I'm spinning up a new architecture for my homelab and personal stuff and that slowness is why I'm installing Gitea for repos and Drone for CI/CD. The combo seems to give me everything I want without taking a huge share of my limited server space.

0xffff2 7y ago

Sluggish and nearly unusable describes every experience I have ever had with GitLab.

dsumenkovic 7y ago
Thanks for the feedback. We are working hard to improve performance and memory consumption of GitLab. We have two major projects underway, switching to Puma [1] as well as reducing the overall memory consumption of GitLab [2]. You can follow along on some of the progress we are making in each release post in the "Performance Improvements" section. For 12.2 you can see we had 58 MR's related to performance. [1] - https://docs.gitlab.com/omnibus/settings/puma.html https://docs.gitlab.com/omnibus/settings/puma.html [2] - https://about.gitlab.com/handbook/engineering/development/enablement/memory/ https://about.gitlab.com/handbook/engineering/development/en... [3] - https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=&state=merged&label_name%5B%5D=performance&milestone_title=12.2 https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=...
- stevekemp 7y ago
  I've heard this from gitlab employees before. Every. Single. Release. For. The. Past. Two. Years. At some point it seems clear that despite statements to the contrary the speed of the instance, and the resource consumption just cannot be a concern. I'd rather the core was speedy and resource-appropriate than see additional half-working features bolted on non-stop, while bug reports languish.
  - emilycook 7y ago
    Hello! We haven't been at the capacity employee-wise to have teams dedicated to improve much in these areas, but we tripled our employee count this year and have since spun up a memory team [1] and are able to dedicate more people to performance [2]. So hopefully we won't be saying this for much longer! --- [1] (same link as #2 above) https://about.gitlab.com/handbook/engineering/development/enablement/memory/ https://about.gitlab.com/handbook/engineering/development/en... [2] https://about.gitlab.com/handbook/engineering/performance/ https://about.gitlab.com/handbook/engineering/performance/

joshlambert 7y ago

Hi - thanks for the feedback, we aren't where we want to be with performance. We are working hard to improve responsiveness and memory consumption, and have a recently started a team focused on just these aspects to accelerate the improvements. You can read more about the rationale here, including stories like yours: https://about.gitlab.com/2019/09/13/why-we-created-the-gitlab-memory-team/ https://about.gitlab.com/2019/09/13/why-we-created-the-gitla... One of the major projects the team is working on, is to switch from unicorn to puma: https://docs.gitlab.com/omnibus/settings/puma.html https://docs.gitlab.com/omnibus/settings/puma.html We are also continuing our broader effort at improving performance each release, for example in 12.2 we had 58 MR's focused on performance improvements: https://about.gitlab.com/2019/08/22/gitlab-12-2-released/#performance-improvements https://about.gitlab.com/2019/08/22/gitlab-12-2-released/#pe... Hopefully you will start to feel the impact of these investments soon.

zrail 7y ago

I'm spinning up a new architecture for my homelab and personal stuff and that slowness is why I'm installing Gitea for repos and Drone for CI/CD. The combo seems to give me everything I want without taking a huge share of my limited server space.