New PR - Slow performance on Windows 1.14

[luiscla27]

• 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.

...

Screenshots

Just the empty screen while GITTEA renders the PR page:

[PaulBol]

Seems to be the same issue like #15413

[zeripath]

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.

[luiscla27]

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

[zeripath]

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.

[luiscla27]

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:

[zeripath]

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

run git repack on the repository

[zeripath]

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