Skip to content
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
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

Closed

Description

@H-Shay

Relevant code begins here:

self.db_pool.updates.register_background_update_handler(

This process can cause excess load on the DB, perhaps need to reconfigure the batch size to make it less resource-intensive.

Activity

  1. added
    A-Background-UpdatesFilling in database columns, making the database eventually up-to-date
    A-DatabaseDB stuff like queries, migrations, new/remove columns, indexes, unexpected entries in the db
    T-TaskRefactoring, removal, replacement, enabling or disabling functionality, other engineering tasks.
    O-OccasionalAffects or can be seen by some users regularly or most users rarely
    S-MinorBlocks non-critical functionality, workarounds exist.
    on Mar 13, 2023
  2. clokep commented on Mar 13, 2023

    @clokep
    Member

    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.

  3. richvdh commented on Mar 14, 2023

    @richvdh
    Member

    For background: we saw a significant slowdown on matrix.org :

    image

    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:

    async def delete_all_from_user_dir(self) -> None:
    """Delete the entire user directory"""
    def _delete_all_from_user_dir_txn(txn: LoggingTransaction) -> None:
    txn.execute("DELETE FROM user_directory")
    txn.execute("DELETE FROM user_directory_search")
    txn.execute("DELETE FROM users_in_public_rooms")
    txn.execute("DELETE FROM users_who_share_private_rooms")
    txn.call_after(self.get_user_in_directory.invalidate_all)
    await self.db_pool.runInteraction(
    "delete_all_from_user_dir", _delete_all_from_user_dir_txn
    )

    ... 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.
  4. reivilibre commented on Mar 23, 2023

    @reivilibre
    Contributor

    We should use TRUNCATE instead of unconditional DELETE FROM, which is faster on Postgres (no table scan).

  5. clokep commented on Apr 4, 2023

    @clokep
    Member

    Do we think #15316 is enough here or is there more to do?

  6. reivilibre commented on Apr 6, 2023

    @reivilibre
    Contributor

    I don't know of anything more to do here for now — do we still see trouble on Matrix.org?

  7. erikjohnston commented on Apr 6, 2023

    @erikjohnston
    Member

    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.

  8. clokep commented on May 18, 2023

    @clokep
    Member

    Even after #15435 we seem to still be at about ~1 Hz FTR.

  9. erikjohnston commented on May 24, 2023

    @erikjohnston
    Member

    Bah, that sounds slower than it was before :(

  10. removed their assignment
    on Jun 1, 2023
  11. DMRobertson commented on Jun 1, 2023

    @DMRobertson
    Contributor

    Let's consider this good enough for now, in the light of #15529 and #15665. Can re-open if this causes future pain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-Background-UpdatesFilling in database columns, making the database eventually up-to-dateA-DatabaseDB stuff like queries, migrations, new/remove columns, indexes, unexpected entries in the dbO-OccasionalAffects or can be seen by some users regularly or most users rarelyS-MinorBlocks non-critical functionality, workarounds exist.T-TaskRefactoring, removal, replacement, enabling or disabling functionality, other engineering tasks.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions