-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request for better performance on paging and lees memory usage on database #31752
Comments
I know why it's getting slower. https://readyset.io/blog/optimizing-sql-pagination-in-postgres |
On slow paging I see this "cache context ..." log entries
|
Step 1: OLD: NEW: Step 2: OLD (expample with LIMIT and OFFSET -> SELECT action.* uses too much memory on database): NEW:
|
Please can you help to confirm #31821 will resolve this issue? |
@lunny yes, I can help. I can check it on my 2nd instance with the same account of data like my main instance. I need an executable gitea-1.21.*-linux-amd64? Nigtly? |
No. It's just a PR. I don't think you can easily replace it to do a test and revert back easily. |
Means I should compile it? Tell me what I have to do? Cause I didn't compile gitea for my use with PostgreSQL. |
No. I can help to compile one but once your upgrade the version I provided, it's difficult for you to downgrade if there is no Gitea develop env for you. |
I have 2nd gitea instance for testing. I can backup the database and after test restore the backup. |
@lunny thx. I tested this PR. My 24/7 NUC with main gitea instance has an Intel Pentium Silver J5005 (4) @ 2.800GHz. The results in this PR was made on this NUC. My test now I run on a faster Intel NUC with an Intel i5-8259U (8) @ 3.800GHz. Has more cores/threads and it's faster. How I made the test.
My expectation is:
I see same projects on the same pages. But the order is reverted. Project which are on the 1. place on the page are in the PR version on the last place. But I see same projects!!! Times: |
Sorry, but I didn't open more page at the beginning. But the new version need less memory or tmp files in PostgreSQL as I show it in my description, |
And on my slower NUC I have 11233 more pages. I wait for you feedback before I restore my DB backup. |
Yes, it's a bug. Please try version 2 https://gitea.com/lunny/packages/src/branch/main/gitea-pr-31821-amd64-linux-2.tar.gz |
I started this Version 1.22.0+rc1-415-gcd09625a76 and the sorting looks good. But I see the times are the same like in 1.22.1 and in PG log I see the action.* query
The second statement should be SELECT action.id FROM ... Like here #31752 (comment) In the first version it was ok
|
In this version, it will use the old code when the page less than 10, otherwise it will use the new code. |
@lunny sounds good, but when you see the OFFSET
SELECT action.* should be uses, cause I'm over 10 pages. And the new method was not used. |
:(. I made a mistake. version 3 https://gitea.com/lunny/packages/src/branch/main/gitea-pr-31821-amd64-linux-3.tar.gz |
Looks good. Page 1-9 old method. Pages 10+ new method. It was good idea to do it. And the sorting looks good too. |
@lunny can I restore my datanse now? Or should I wait? |
Yes, you can restore now. Thank you for your testing. |
I have to thank you for the implementation of the PR. |
@lunny I installed 1.22.3 release. I saw the changes. I see this
SQL on paging. I was sure, the change will be:
which in my case need 50% of the time in the higher pages and uses only 10% of the memory. vs |
Please follow #32224 |
Feature Description
I'm again. The gitea user with 3655 organisations and 22573 repos.
I wondered that my paging is slow. Not on the first pages.
First page need 1-3 seconds. 1 second if the data is precached.
On the last pages ...
But this is after my 1st optimisation.
You made this queries
on pagging.
Explain for the count query is
And than I changed the query to
SELECT count(action.id) FROM "action" INNER JOIN "repository" ON "repository".id = "action".repo_id WHERE user_id=$1 AND is_deleted=$2
and ...
it's faster.
Explain for the SELECT query is
very bad. I increased work_mem to 6GB and it's better now
After this fix it need ~11 seconds.
But it can be better. Cause the problem is this
SELECT action.* FROM action INNER JOIN repository ON repository.id = action.repo_id WHERE user_id='1' AND is_deleted='f' ORDER BY action.created_unix DESC LIMIT 20 OFFSET 2043740
query. When you change it to
SELECT action.id FROM action INNER JOIN repository ON repository.id = action.repo_id WHERE user_id='1' AND is_deleted='f' ORDER BY action.created_unix DESC LIMIT 20 OFFSET 2043740
-> you will get 20 action.id's than explain is
and need ~5 seconds and a very less memory on the database.
Than gitea should get the action.* infos only for the 20 id's in the new query.
This optimisation will be good for all gitea users.
Screenshots
No response
The text was updated successfully, but these errors were encountered: