Nettoyage du serveur synapse

Depuis plus de 12 mois notre serveur Synapse n'a pas été nettoyé, et il est devenu ingérable en terme d'espace occupé. La BDD fait 1.1To, les accès disque dessus commencent à saturer les SSD de aegir.

Cette issue documente les travaux en cours, étape par étape, pour servir de base à une automatisation de la plus grande partie possible des actions, au delà de ce qui est déjà fait par synatainer.

added Progression / En cours label

added Importance / Haute Scope / Application & Services labels

changed the description

On commence par un état des lieux de ce qui consomme le plus, simplement \dt+

public | current_state_delta_stream                     | table | matrix | permanent   | heap          | 9758 MB    |
public | device_inbox                                   | table | matrix | permanent   | heap          | 19 GB      |
public | device_lists_changes_in_room                   | table | matrix | permanent   | heap          | 45 GB      |
public | event_auth                                     | table | matrix | permanent   | heap          | 15 GB      |
public | event_edges                                    | table | matrix | permanent   | heap          | 16 GB      |
public | event_search                                   | table | matrix | permanent   | heap          | 19 GB      |
public | events                                         | table | matrix | permanent   | heap          | 23 GB      |
public | event_json                                     | table | matrix | permanent   | heap          | 121 GB     |
public | room_memberships                               | table | matrix | permanent   | heap          | 5877 MB    |
public | state_groups_state                             | table | matrix | permanent   | heap          | 338 GB     |

Attention, la consommation ici n'inclut pas les index, les state groups state consomment en réalité plus de 500Go.

public | device_lists_changes_in_room_by_room_idx                        | index | matrix | device_lists_changes_in_room                   | permanent   | btree         | 31 GB      |
public | device_lists_changes_in_stream_id                               | index | matrix | device_lists_changes_in_room                   | permanent   | btree         | 25 GB      |
public | ev_edges_prev_id                                                | index | matrix | event_edges                                    | permanent   | btree         | 10 GB      |
public | event_edges_event_id_prev_event_id_idx                          | index | matrix | event_edges                                    | permanent   | btree         | 21 GB      |
public | event_json_event_id_key                                         | index | matrix | event_json                                     | permanent   | btree         | 10 GB      |
public | event_search_event_id_idx                                       | index | matrix | event_search                                   | permanent   | btree         | 6222 MB    |
public | events_jump_to_date_idx                                         | index | matrix | events                                         | permanent   | btree         | 6570 MB    |
public | events_order_room                                               | index | matrix | events                                         | permanent   | btree         | 8750 MB    |
public | events_room_stream                                              | index | matrix | events                                         | permanent   | btree         | 7767 MB    |
public | state_groups_state_type_idx                                     | index | matrix | state_groups_state                             | permanent   | btree         | 167 GB     |

Le volume de chaque table est imortant en particulier dans la situation où l'espace disponible global est < 100Go. On peut nettoyer une table, mais si elle fait plus que l'espace disponible, indexes compris, on ne pourra pas la vacuum facilement, donc récupérer de l'espace.

Pour tout nettoyer, on utilise massivement l'API d'admin de synapse via synadm tel que proposé ici : https://tedomum.net/service/matrix/administration/

On dump les rooms et les users pour les analyses. Dumper dans un fichier permet d'éviter de spam l'API pour générer des rapports différents. On refait la requête à partir de l'API pour avoir des données fraiches une fois qu'on a fait le tour.

synadm GET 'v1/rooms?limit=999999' > rooms.json
synadm GET 'v2/users?limit=999999' > users.json

On commence par un compte rapide :

cat rooms.json| jq '.rooms[]|.room_id' | wc -l                                                        
  19458
cat users.json |jq '.users[]|.name' | wc -l
   7377

D'autres comptes de début de parcours directement en SQL :

matrix=# select count(*) from devices;
 count
-------
 17324

matrix=# select count(*) from device_inbox;
  count
----------
 11539595

matrix=# select count(*) from state_groups_state ;
   count
------------
 2318198633

La logique est la suivante : il faut libérer de l'espace, d'abord à côté de state groups states pour pouvoir récupérer assez d'espace et ensuite vacuum les state groups.

On se concentre donc d'abord sur supprimer des rooms. Et pour supprimer des rooms il faut des rooms vides ou périmées, on commence donc par essayer de désactiver des utilisateurs. La première catégorie supprimée, les guests, est désactivée depuis 4 ans sur le serveur et ne sera bientôt plus supportée du tout.

cat users.json |jq '.users[]|select(.is_guest==true)|select(.deactivated==false)|.name' > guests
wc -l guests
   3516

On supprime en mode erase, qui active la suppression GDPR, en particulier les nouveaux rejoignant une room ne verront pas les messages de ces users.

for u in $(cat guests); do echo $u; synadm POST "v1/deactivate/$u" -d '{"erase":true}' ; done

On a gagné environ 50% d'users sur le serveur, même s'ils étaient globalement dans peu de rooms :

synadm GET 'v2/users?limit=999999' | jq '.users[]|.name' |wc -l

On récupère les rooms en supprimant les rooms vides, du moins vides d'utilisateurs locaux. On les repère simplement :

cat rooms.json| jq '.rooms[]|select(.joined_local_members==0)|.room_id'

La suppression nécessite l'appel à l'API de purge de room et le suivi de l'état de la purge. Heureusement un script synatainer fait déjà tout ça pour les rooms vides :

docker compose run --rm synatainer /usr/local/bin/purge_rooms_no_local_members.sh

Pour 500 rooms et vu l'état des state groups et des index associés, compter 2 à 3 jours :)

On supprime également quelques rooms très consommatrices de ressources, notamment de state groups.

select room_id, count(*) cnt from state_groups_state group by room_id order by cnt desc;

Parmi les rooms on repère dans le top 50 les candidats pour suppression simple :

synadm GET 'v1/rooms/!ping-v9:maunium.net' | jq

Puis on supprime :

synadm DELETE 'v2/rooms/!ping-v9:maunium.net' -d '{"message":"Room is too big for this HS", "block": true, "purge": true}'

La suppression de chaque room de ce type prend plusieurs heures au début. L'impact est notable après quelques étapes, en particulier sur les state groups :

matrix=# select count(*) from state_groups_state;

   count
------------
 1425558248

Soit déjà 40% de gain.

Compression systématique des state groups. En attendant d'avoir récupéré suffisamment de place pour vacuum les state groups, on commence par en diminuer le nombre. Notamment en compressant leur structure grâce à l'outil de compression synapse_compress_state embarqué dans l'image synatainer.

On dump la liste des rooms ids :

synadm GET 'v1/rooms?limit=99999' | jq '.rooms[]|.room_id' -r > rooms

On charge la liste dans l'image synatainer et on y ouvre un shell (on évite le run et la création du conteneur pour chaque room), puis :

for r in $(cat rooms); do date; synapse_compress_state -p "postgresql://$DB_USER:$PGPASSWORD@[$DB_HOST]/$DBNAME" -r "$r"; echo; done