github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-10 22:06:34 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

New PR - Slow performance on Windows 1.14 #7182

New Issue
Closed
opened 2025-11-02 07:18:40 -06:00 by GiteaMirror · 7 comments
GiteaMirror commented 2025-11-02 07:18:40 -06:00
Owner
Copy Link

Originally created by @luiscla27 on GitHub (Apr 15, 2021).

  • Gitea version (or commit ref): 1.14.0 built with GNU Make 4.1, go1.16.3 : bindata, sqlite, sqlite_unlock_notify
  • Git version: 2.26.2.windows.1
  • Operating system: Windows Server 2019 Standard

We used one of your downloads, updates are made by gittea's update feature.
Gitea is running as a windows service

  • Database (use [x]):
    • PostgreSQL
    • MySQL (MariaDB v10.4.12)
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (I didn't tried)
    • No
  • Log gist:
    logs-gitea.zip

Description

First, this is maybe a regression issue, the previous version of GITTEA didn't had this low performance.

I tried to make a pull request with the following characteristics and it got stuck by 10 minutes, my guess that the process that gathers all the revision changes got a performance issue recently.

The reason I think is a regression is because I've done PR's this big before the update with no issue.
image

...

Screenshots

Just the empty screen while GITTEA renders the PR page:
image

Originally created by @luiscla27 on GitHub (Apr 15, 2021). - Gitea version (or commit ref): 1.14.0 built with GNU Make 4.1, go1.16.3 : bindata, sqlite, sqlite_unlock_notify - Git version: 2.26.2.windows.1 - Operating system: Windows Server 2019 Standard We used one of your downloads, updates are made by gittea's update feature. Gitea is running as a windows service - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL (**MariaDB v10.4.12**) - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (I didn't tried) - [ ] No - Log gist: [logs-gitea.zip](https://github.com/go-gitea/gitea/files/6314823/logs-gitea.zip) ## Description First, this is maybe a regression issue, the previous version of GITTEA didn't had this low performance. I tried to make a pull request with the following characteristics and it got stuck by 10 minutes, my guess that the process that gathers all the revision changes got a performance issue recently. The reason I think is a regression is because I've done PR's this big before the update with no issue. ![image](https://user-images.githubusercontent.com/29953012/114804537-0bcb5780-9d67-11eb-93ac-be60777899e5.png) ... ## Screenshots Just the empty screen while GITTEA renders the PR page: ![image](https://user-images.githubusercontent.com/29953012/114804474-f1917980-9d66-11eb-9fd3-408585e564c6.png)
GiteaMirror added the issue/duplicate label 2025-11-02 07:18:40 -06:00
GiteaMirror commented 2025-11-02 07:18:41 -06:00
Author
Owner
Copy Link

@PaulBol commented on GitHub (Apr 15, 2021):

Seems to be the same issue like #15413

@PaulBol commented on GitHub (Apr 15, 2021): Seems to be the same issue like #15413
GiteaMirror commented 2025-11-02 07:18:41 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Apr 15, 2021):

yup marking as duplicate.

@luiscla27 please try:

https://eldritchkitty.com/~andrew/gitea-1.14.0-gogit-windows-4.0-amd64.exe

It should be noted that reason that we moved from GoGit was because of memory issues - it is not frugal at all with loading data in to memory, and we made that move over 3 months ago on master. We had around a month of RC to find out these issues and no-one using windows took that time to try the RCs and then report that this was an issue.

The underlying issue is that starting git is just slow on Windows for whatever reason - be that due to go, windows or git-for-windows. Not being a windows user myself I am uncertain how to find out how to speed that up , everything I've suggested so far seems to have been ineffective - and no-one using Windows has made suggestions. I've made several attempts at reducing process calls but it is unlikely that the pure git backend can be made performant enough for windows users so we'll have to provide go-git builds for you for the moment.

We rely on the community to test our builds and if the community doesn't test until release day - well... this is what happens.

In regards to the provided logs - please read the https://docs.gitea.io/en-us/logging-configuration/#debugging-problems when submitting logs. The logs you have submitted are basically just SQL logs which are rarely helpful - and you shouldn't really be logging these anyway - and are running at INFO level only!

The logging configuration is highly configurable - you really should consider setting your default log configuration to:

[database]
LOG_SQL = false ; SQL logs are rarely helpful unless we specifically ask for them

...

;; Now depending on how you like things to be logged - if it's straight to file - well this way puts everything in one file:
[log]
MODE=file
LEVEL=info ; If you're submitting issues though this needs to be DEBUG
REDIRECT_MACARON_LOG=true
MACARON=,
ROUTER=,

;; If you're a console person - this will give nice colourful logs.
[log]
MODE=console
LEVEL=info ; If you're submitting issues though this needs to be DEBUG
REDIRECT_MACARON_LOG=true
MACARON=console
ROUTER=console

The access.log can be set-up as you need with ACCESS as appropriate.

In fact on 1.14 we now have the ability to adjust logging whilst running with gitea manager logging add and remove.

For example, you could temporarily add a file mode logger at debug with:

gitea manager logging add file -n debugfile  -f log/debug.log -l debug

(similarly for console)

In particular you can add trace logging for particular expressions with:

gitea manager logging add console -n traceconsole -l trace -e <EXPRESSION>

Where can be anything logged, including the filename that contains the logging expression.

@zeripath commented on GitHub (Apr 15, 2021): yup marking as duplicate. @luiscla27 please try: https://eldritchkitty.com/~andrew/gitea-1.14.0-gogit-windows-4.0-amd64.exe It should be noted that reason that we moved from GoGit was because of memory issues - it is not frugal at all with loading data in to memory, and we made that move over 3 months ago on master. We had around a month of RC to find out these issues and no-one using windows took that time to try the RCs and then report that this was an issue. The underlying issue is that starting git is just slow on Windows for whatever reason - be that due to go, windows or git-for-windows. Not being a windows user myself I am uncertain how to find out how to speed that up , everything I've suggested so far seems to have been ineffective - and no-one using Windows has made suggestions. I've made several attempts at reducing process calls but it is unlikely that the pure git backend can be made performant enough for windows users so we'll have to provide go-git builds for you for the moment. We rely on the community to test our builds and if the community doesn't test until release day - well... this is what happens. --- In regards to the provided logs - please read the https://docs.gitea.io/en-us/logging-configuration/#debugging-problems when submitting logs. The logs you have submitted are basically just SQL logs which are rarely helpful - and you shouldn't really be logging these anyway - and are running at INFO level only! The logging configuration is highly configurable - you really should consider setting your default log configuration to: ```ini [database] LOG_SQL = false ; SQL logs are rarely helpful unless we specifically ask for them ... ;; Now depending on how you like things to be logged - if it's straight to file - well this way puts everything in one file: [log] MODE=file LEVEL=info ; If you're submitting issues though this needs to be DEBUG REDIRECT_MACARON_LOG=true MACARON=, ROUTER=, ;; If you're a console person - this will give nice colourful logs. [log] MODE=console LEVEL=info ; If you're submitting issues though this needs to be DEBUG REDIRECT_MACARON_LOG=true MACARON=console ROUTER=console ``` The access.log can be set-up as you need with `ACCESS` as appropriate. --- In fact on 1.14 we now have the ability to adjust logging whilst running with `gitea manager logging add` and `remove`. For example, you could temporarily add a `file` mode logger at `debug` with: ``` gitea manager logging add file -n debugfile -f log/debug.log -l debug ``` (similarly for console) In particular you can add trace logging for particular expressions with: ``` gitea manager logging add console -n traceconsole -l trace -e <EXPRESSION> ``` Where <expression> can be anything logged, including the filename that contains the logging expression.
GiteaMirror commented 2025-11-02 07:18:41 -06:00
Author
Owner
Copy Link

@luiscla27 commented on GitHub (Apr 15, 2021):

Thank you for your quick feedback @zeripath, we'll try the go-git build,

btw, is there a risk of installing that package? some of my colleagues are concerned that after installing it, later returning to the master version somehow counts as a downgrade that might risk our repository.

Also, sorry about the previous log... I just got copy/pasted it. Here I'm attaching a cleaner one which includes only log information since the windows service started to the moment the issue occurs.
gitea.log

@luiscla27 commented on GitHub (Apr 15, 2021): Thank you for your quick feedback @zeripath, we'll try the go-git build, btw, is there a risk of installing that package? some of my colleagues are concerned that after installing it, later returning to the master version somehow counts as a downgrade that might risk our repository. Also, sorry about the previous log... I just got copy/pasted it. Here I'm attaching a cleaner one which includes only log information since the windows service started to the moment the issue occurs. [gitea.log](https://github.com/go-gitea/gitea/files/6318461/gitea.log)
GiteaMirror commented 2025-11-02 07:18:42 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Apr 15, 2021):

The linked build was built on 1.14.0 ...

Just take a backup of your db if you're really concerned.

We're currently in the process of getting 1.14.1 ready for submission and gogit builds will be built for windows on that.

@zeripath commented on GitHub (Apr 15, 2021): The linked build was built on 1.14.0 ... Just take a backup of your db if you're really concerned. We're currently in the process of getting 1.14.1 ready for submission and gogit builds will be built for windows on that.
GiteaMirror commented 2025-11-02 07:18:42 -06:00
Author
Owner
Copy Link

@luiscla27 commented on GitHub (Apr 15, 2021):

We installed the go-git package and some repositories stopped working...

We returned to the previous Gitea build and didn't tried to find the cause, now is working. I just wanted to share this issue to you @zeripath. Here's the log.

Some forks show error 500 by just trying to open them:
image

@luiscla27 commented on GitHub (Apr 15, 2021): We installed the go-git package and some repositories stopped working... We returned to the previous Gitea build and didn't tried to find the cause, now is working. I just wanted to share this issue to you @zeripath. Here's the [log](https://github.com/go-gitea/gitea/files/6319865/gitea-gitea-1.14.0-gogit-windows-4.0-amd64.log). Some forks show error 500 by just trying to open them: ![image](https://user-images.githubusercontent.com/29953012/114907690-f4c94b80-9de0-11eb-9ee2-98ef6fd4a1f0.png)
GiteaMirror commented 2025-11-02 07:18:42 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Apr 15, 2021):

2021/04/15 11:24:46 ...ules/context/repo.go:772:func1() [E] GetBranchCommit: packfile not found

run git repack on the repository

@zeripath commented on GitHub (Apr 15, 2021): ``` 2021/04/15 11:24:46 ...ules/context/repo.go:772:func1() [E] GetBranchCommit: packfile not found ``` run git repack on the repository
GiteaMirror commented 2025-11-02 07:18:42 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Apr 15, 2021):

(This is another reason why we were trying to get off gogit)

@zeripath commented on GitHub (Apr 15, 2021): (This is another reason why we were trying to get off gogit)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#7182
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?