Aphront Exception since recent update

Hello, since a recent Debian upgrade (to 10.8) earlier this year Diffusion often runs into timeouts.
Everything was updated, including PHP (7.4) and Mariadb (10.3) as well as Phabricator itself. Everything runs on the same machine and is stored on an SSD drive.

I suspect it’s a setup issue but I don’t know how to debug this properly. Two weeks ago I hacked to the source code to increase the timeout and the timeouts appeared to be fixed but now it’s starting again (I reverted the local change).

The mariadb error log is full of lines like this, which I think means that the application aborted the query?

2021-02-16 10:25:52 2542134 [Warning] Aborted connection 2542134 to db: 'phabricator_repository' user: 'phabricator' host: 'localhost' (Got an error writing communication packets)
2021-02-16 10:25:52 2542122 [Warning] Aborted connection 2542122 to db: 'phabricator_repository' user: 'phabricator' host: 'localhost' (Got an error writing communication packets)
2021-02-16 10:25:52 2542114 [Warning] Aborted connection 2542114 to db: 'phabricator_repository' user: 'phabricator' host: 'localhost' (Got an error writing communication packets)
2021-02-16 10:25:58 2542140 [Warning] Aborted connection 2542140 to db: 'phabricator_repository' user: 'phabricator' host: 'localhost' (Got an error writing communication packets)
2021-02-16 10:26:03 2542205 [Warning] Aborted connection 2542205 to db: 'phabricator_repository' user: 'phabricator' host: 'localhost' (Got an error writing communication packets)
2021-02-16 10:28:03 2541744 [Warning] Aborted connection 2541744 to db: 'phabricator_daemon' user: 'phabricator' host: 'localhost' (Got timeout reading communication packets)

I found about mytop and checked what it says. When I browse a diffusion page that times out it shows that queries like Sending data SELECT commitID, pathID FROM repository_pathchange WHERE commitID IN (1622016, 1622017, 1622018, 1622019, 1622020, 1622021, … take a very long time (many minutes). I increased the Aphront query timeout to 150s now without success.

I think we have lots of queries of the form IN (id, id, id, id...).
Maybe check the indexes on this specific table?

Navigating to /config/dbissue/ should show obvious issues, and ./bin/storage adjust should fix them.

The page says “No databases have any issues.”. /config/database/ says “No Schema Issues”

/config/cluster/databases/ shows this

We don’t use replication / clusters. The (only) database server is on the same machine.