analysis on performance bottlenecks in repo migration #6911

New Issue

2025-11-02T07:10:53-06:00

GiteaMirror commented

2025-11-02 07:10:53 -06:00

Originally created by @noerw on GitHub (Feb 22, 2021).

Repo migration from Github can take a long time (eg this gitea repo takes more than 24h on a small VPS (hetzner CPX11)).
It's unclear (to me) if this is incurred by ratelimits of external services (GH API), or due to inefficiencies in Giteas migration module.

The aim of this issue is to identify the bottlenecks involved. For now the primary method for this is to collect pprof profiles, to investigate in which routines most time is spent.
This partly also gives insight into which network, disk, DB operations take much time, but only indirectly. For that, analyzing DB query times specifically might be more helpful. (If somebody can outline a good process for that, a comment here would be appreciated ;)

I sampled some pprof activity during a migration of https://github.com/go-gitea/gitea, including all entities except for releases, gitea 1.14.0+dev-713-gec06eb112. which ran over several hours. You can find several pprof profiles that were sampled for 30 seconds - 30 minutes attached:
pprof.gitea.samples.cpu.00.zip

To inspect them run go tool pprof -http :8080 <path to profile>
To collect you own profiles, set ENABLE_PPROF = true under [server] in app.ini, then call go tool pprof -seconds 1800 0.0.0.0:6060

Actual analysis of these samples will follow in the upcoming days..

Server utilization graphs for the middle 12 hours of migration:

This looks to me like the higher-utilization phases each hour are related to a reset of the github ratelimiter window, so we're down to ~33% of potential performance just through github ratelimits

Originally created by @noerw on GitHub (Feb 22, 2021). Repo migration from Github can take a long time (eg this gitea repo takes more than 24h on a small VPS (hetzner CPX11)). It's unclear (to me) if this is incurred by ratelimits of external services (GH API), or due to inefficiencies in Giteas migration module. The aim of this issue is to identify the bottlenecks involved. For now the primary method for this is to collect **pprof profiles**, to investigate in which routines most time is spent. This partly also gives insight into which network, disk, DB operations take much time, but only indirectly. For that, analyzing DB query times specifically might be more helpful. (If somebody can outline a good process for that, a comment here would be appreciated ;) I sampled some pprof activity during a migration of `https://github.com/go-gitea/gitea`, including all entities except for releases, gitea `1.14.0+dev-713-gec06eb112`. which ran over several hours. You can find several pprof profiles that were sampled for 30 seconds - 30 minutes attached: [pprof.gitea.samples.cpu.00.zip](https://github.com/go-gitea/gitea/files/6022293/pprof.gitea.samples.cpu.00.zip) - To inspect them run `go tool pprof -http :8080 <path to profile>` - To collect you own profiles, set `ENABLE_PPROF = true` under `[server]` in `app.ini`, then call `go tool pprof -seconds 1800 0.0.0.0:6060` Actual analysis of these samples will follow in the upcoming days.. Server utilization graphs for the middle 12 hours of migration: ![grafik](https://user-images.githubusercontent.com/7880552/108719695-cbdeb580-7517-11eb-8801-b6c9923ee122.png) This looks to me like the higher-utilization phases each hour are related to a reset of the github ratelimiter window, so we're down to ~33% of potential performance just through github ratelimits

GiteaMirror added the performance/bigrepo performance/speed topic/repo-migration issue/needs-feedback labels 2025-11-02 07:10:53 -06:00

GiteaMirror closed this issue

2025-11-02 07:10:53 -06:00

GiteaMirror commented

2025-11-02 07:10:53 -06:00

@lunny commented on GitHub (Feb 22, 2021):

A possible resolution to break rate limit is to create multiple account and migrations support multiple tokens.

@lunny commented on GitHub (Feb 22, 2021): A possible resolution to break rate limit is to create multiple account and migrations support multiple tokens.

GiteaMirror commented

2025-11-02 07:10:54 -06:00

@zeripath commented on GitHub (Feb 22, 2021):

quick and dirty look through those samples suggests just downloading and storing the releases is what's taking the time.

There's some delay due to encoding/json and it might be that using jsoniter here is a little quicker but I'm not certain it's huge.

@zeripath commented on GitHub (Feb 22, 2021): quick and dirty look through those samples suggests just downloading and storing the releases is what's taking the time. There's some delay due to encoding/json and it might be that using jsoniter here is a little quicker but I'm not certain it's huge.

GiteaMirror commented

2025-11-02 07:10:54 -06:00

@lunny commented on GitHub (Jun 7, 2021):

#16070 may give some help for this issue.

@lunny commented on GitHub (Jun 7, 2021): #16070 may give some help for this issue.

GiteaMirror commented

2025-11-02 07:10:54 -06:00

@wxiaoguang commented on GitHub (Apr 8, 2025):

It has been a long time since the report, outdated?

@wxiaoguang commented on GitHub (Apr 8, 2025): It has been a long time since the report, outdated?

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#6911