diff options
| author | Patrick Steinhardt <psteinhardt@gitlab.com> | 2023-05-09 11:28:20 +0300 |
|---|---|---|
| committer | Patrick Steinhardt <psteinhardt@gitlab.com> | 2023-05-09 11:28:20 +0300 |
| commit | fdd48e61b990e7b1dd2389f6abfcfcf0c3004730 (patch) | |
| tree | 5e58e9d79a6c82d2f108075774960fcf739bd860 | |
| parent | bf616bd24e576aa6792f1a9173ca68cc32d42319 (diff) | |
housekeeping: Default-enable geometric repacking
We have rolled out geometric repacking into production systems two weeks
ago now. Key observations:
- On a global scale, we see a decrease in time spent optimizing
repositories of 15-30%.
- On a smaller scale, we see a decrease in time spent optimizing
repositories in the gitlab-org and gitlab-com groups of 70-85%.
As geometric repacking is especially thought to be a win in large
monorepositories that have a lot of activity these observations match
the expectations that we have. Our gitlab-org and gitlab-com groups host
two of the most active repositories that are also quite large with the
gitlab and www-gitlab-com repositories, so it is expected that we see a
large win there.
On the global scale the win is expected to be less significant as we
tend to do full repacks more frequently in repositories with less
activity now. But given that we still see a win there this seems to not
be an issue.
Let's default-enable the feature flag so that we can remove it in the
next release.
Changelog: performance
| -rw-r--r-- | internal/metadata/featureflag/ff_geometric_repacking.go | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/internal/metadata/featureflag/ff_geometric_repacking.go b/internal/metadata/featureflag/ff_geometric_repacking.go index d4d91bb8d..8665b9d21 100644 --- a/internal/metadata/featureflag/ff_geometric_repacking.go +++ b/internal/metadata/featureflag/ff_geometric_repacking.go @@ -6,5 +6,5 @@ var GeometricRepacking = NewFeatureFlag( "geometric_repacking", "v15.11.0", "https://gitlab.com/gitlab-org/gitaly/-/issues/5031", - false, + true, ) |