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
[Bug]: 0.19.4-beta.6
performance issues
#4681
Comments
0.19.4-beta.6
DB performance issues0.19.4-beta.6
performance issues
K here's an explain analyze. The "Trigger Name": "update_statement" seems to be the culprit.
|
can you post the query you ran? |
Here's the slow trigger
|
The query:
I'm downgrading lemmy.ml for now tho, we need to fix this locally and spend some more time on this. @dullbananas lemmy.ml is back on |
@dessalines Could you check the execution time of each statement executed by the trigger? It might be possible by using auto_explain with log_triggers and log_analyze enabled. |
Have you tried to reproduce this with the db_perf crate? |
@dullbananas https://paste.centos.org/view/e746389e There's a few comment inserts that take >30s, with trigger logging enabled, but it doesn't seem to show what's specifically slow. Also noteworthy that this affects not just comment inserts, but every insert, person, post, etc. |
Looks like this is a problem specifically for update or upsert. Edit: this is probably wrong because the insert_statement trigger would run with 0 rows as input in this case |
The duration of the transaction done when inserting a comment is probably a big contributing factor. ShareLock is used to wait for another transaction to finish. |
I think this is the main problem: in the new triggers, the update to site_aggregates is not the last statement, but it probably was previously the last trigger to run because "site" is far down in alphabetical order. This would extend the duration from the start of the site_aggregates update to the end of the whole transaction, which is the period in which concurrent writers are blocked. Avoiding this problem is far more crucial for site_aggregates than for other tables because all local insertions update the same row in site_aggregates. |
So just moving that statement to the bottom of the trigger would fix it? We already have some site_aggregates and community_aggregates updates in scheduled tasks run every hour, so to me a lot of these non-crucial "site stat" type ones it makes sense to move out of triggers. |
Yes, and that's one of the things done in #4696 |
Closing this, as #4696 is merged, and it fixed the issues 🤞 . Can re-open if more pop up. |
Requirements
Summary
We recently upgraded lemmy.ml to
0.19.4-beta.6
, as well as upgraded to postgres 16, and some things are going much slower. I'm not sure of the culprit, but here are a few slow ones.comment insert:
person insert:
The standard post query is also slower.
Also getting a lot of these sharelocks:
I'm also seeing the
lemmy-federate
process having a very high CPU usage, >400%Steps to Reproduce
See above
Technical Details
Same
Version
0.19.4-beta.6
Lemmy Instance URL
main
The text was updated successfully, but these errors were encountered: