You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
Improve performance of background update populate_user_directory_process_rooms #15264
The main issue (from my understanding) is that it reports based on the number of rooms which are processed, but rooms vary in how "expensive" they are. Maybe using something like rooms * users_in_room would be better?
That might allow the background update algorithm to process it a bit more reasonably.
For background: we saw a significant slowdown on matrix.org :
This appears to have aligned with some work done by the populate_user_directory_process_rooms background database update. In particular, the update starts with a big delete:
... which, based on postgres's slow query logs, completed at 21:12 UTC on 2023-03-13, exactly coinciding with the first spike in the above graph.
The main issue (from my understanding) is that it reports based on the number of rooms which are processed, but rooms vary in how "expensive" they are. Maybe using something like rooms * users_in_room would be better?
I'm not convinced that's the main issue. Certainly the updates are quite expensive, but empirically the delete caused a problem too - and it's much harder to break down into small steps.
To be determined here:
why does a delete in users_who_share_private_rooms cause a significant slowdown in event persistence
this was far from the only spike in event persistence times over the course of the evening: there were others at 20:15 and a long slowdown between 18:00 and 18:25. It is currently unknown what caused them.
Empirically its doing ~1Hz of room processing on matrix.org, which is going to take months?
We should have a look at what queries its doing etc and see if we can speed it up. We can just turn on DEBUG logging on the background worker to see what its doing.
Activity
clokep commentedon Mar 13, 2023
The main issue (from my understanding) is that it reports based on the number of rooms which are processed, but rooms vary in how "expensive" they are. Maybe using something like
rooms * users_in_roomwould be better?That might allow the background update algorithm to process it a bit more reasonably.
richvdh commentedon Mar 14, 2023
For background: we saw a significant slowdown on
matrix.org:This appears to have aligned with some work done by the
populate_user_directory_process_roomsbackground database update. In particular, the update starts with a big delete:synapse/synapse/storage/databases/main/user_directory.py
Lines 583 to 595 in 335f52d
... which, based on postgres's slow query logs, completed at 21:12 UTC on 2023-03-13, exactly coinciding with the first spike in the above graph.
I'm not convinced that's the main issue. Certainly the updates are quite expensive, but empirically the delete caused a problem too - and it's much harder to break down into small steps.
To be determined here:
users_who_share_private_roomscause a significant slowdown in event persistencereivilibre commentedon Mar 23, 2023
We should use
TRUNCATEinstead of unconditionalDELETE FROM, which is faster on Postgres (no table scan).clokep commentedon Apr 4, 2023
Do we think #15316 is enough here or is there more to do?
reivilibre commentedon Apr 6, 2023
I don't know of anything more to do here for now — do we still see trouble on Matrix.org?
erikjohnston commentedon Apr 6, 2023
Empirically its doing ~1Hz of room processing on matrix.org, which is going to take months?
We should have a look at what queries its doing etc and see if we can speed it up. We can just turn on DEBUG logging on the background worker to see what its doing.
User directory background update speedup (#15435)
clokep commentedon May 18, 2023
Even after #15435 we seem to still be at about ~1 Hz FTR.
erikjohnston commentedon May 24, 2023
Bah, that sounds slower than it was before :(
DMRobertson commentedon Jun 1, 2023
Let's consider this good enough for now, in the light of #15529 and #15665. Can re-open if this causes future pain.