Update Article “2021-07-12-chroniques-administration-synapse”
This commit is contained in:
parent
ab1b5c541e
commit
b64825fb7b
|
|
@ -6,14 +6,14 @@ sitemap: true
|
|||
title: Chroniques d'administration de Synapse
|
||||
description: Pour l'instant tout va bien, pour l'instant tout...
|
||||
category: operation
|
||||
tags:
|
||||
tags: null
|
||||
date: 2023-02-28T11:06:23.433+01:00
|
||||
---
|
||||
|
||||
Tout a commencé le mercredi 30 juin par un message parfaitement innocent de Max qui nous dit que les disques sont presque pleins :
|
||||
|
||||
|
||||
|
||||
Pour éviter la catastrophe annoncée, je décide de trouver le coupable.
|
||||
Pour éviter la catastrophe annoncée, je décide de trouver le coupable.
|
||||
Après une rapide recherche, il apparait que PostgreSQL occupe plus de 50Go.
|
||||
Ayant des SSD de 120 Go, c'est donc majoritairement PostgreSQL qui occupe de la place.
|
||||
En creusant plus profondément, c'est la base de donnée de Synapse (le serveur Matrix) qui prend tout cet espace, les autres bases ne comptant que pour quelques kilo-octets.
|
||||
|
|
@ -27,8 +27,9 @@ Pour finir de planter le décor, notre instance Matrix a 4 ans mais n'a jamais n
|
|||
Sûr de moi, je vise une petite maintenance de deux heures où je compte supprimer les salons de discussions vides et réduire l'historique distant des salons très bruyants. La documentation sur le sujet est quasi inexistante mais je me dis que c'est parce que la tâche ne doit pas être si complexe. En réalité, la maintenance durera 4 jours et ne se sera pas passée du tout comme prévu. Je vous propose de revenir ici sur tous les points qui ont bloqué !
|
||||
|
||||
Avant d'aller plus loin, je souhaite souligner l'existence de deux guides sur le sujet qui m'ont aidé et qui sont de très bons compléments à cet article :
|
||||
- [Compressing Synapse database](https://levans.fr/shrink-synapse-database.html) par Levans
|
||||
- [Administration Synapse > Nettoyage du serveur](https://www.tedomum.net/dev/service/matrix/administration/#nettoyage-du-serveur) par Tedomum
|
||||
|
||||
- [Compressing Synapse database](https://levans.fr/shrink-synapse-database.html) par Levans
|
||||
- [Administration Synapse > Nettoyage du serveur](https://www.tedomum.net/dev/service/matrix/administration/#nettoyage-du-serveur) par Tedomum
|
||||
|
||||
## L'API d'administration de Synapse
|
||||
|
||||
|
|
@ -55,10 +56,10 @@ La mise en route est rapide : il faut commencer par passer un compte Synapse en
|
|||
UPDATE users SET admin = 1 WHERE name = '@foo:bar.com';
|
||||
```
|
||||
|
||||
Ensuite, il faut récupérer un *bearer* pour ce compte.
|
||||
Pour ma part, je me suis simplement connecté sur Element avec puis j'ai utilisé l'inspecteur réseau de mon navigateur, regardé les détails d'une requête partant vers l'API et extrait l'entête *Authorization* qui contient le *bearer*.
|
||||
Ensuite, il faut récupérer un _bearer_ pour ce compte.
|
||||
Pour ma part, je me suis simplement connecté sur Element avec puis j'ai utilisé l'inspecteur réseau de mon navigateur, regardé les détails d'une requête partant vers l'API et extrait l'entête _Authorization_ qui contient le _bearer_.
|
||||
|
||||
Enfin, pour ne pas retaper le bearer à chaque fois, je définis un alias pour ma session (il faut remplacer les points d'interogation avec le *bearer* que vous avez récupéré précédemment !) :
|
||||
Enfin, pour ne pas retaper le bearer à chaque fois, je définis un alias pour ma session (il faut remplacer les points d'interogation avec le _bearer_ que vous avez récupéré précédemment !) :
|
||||
|
||||
```bash
|
||||
alias mctl='curl --header "Authorization: Bearer ???"'
|
||||
|
|
@ -72,7 +73,7 @@ mctl 'https://synapse.tld/_synapse/admin/v2/users?from=0&limit=0&guests=true'
|
|||
```
|
||||
|
||||
Maintenant qu'on a le nombre, on va vouloir récupérer la liste.
|
||||
À vous de choisir si vous voulez écrire un script utilisant le système de pagination de l'API
|
||||
À vous de choisir si vous voulez écrire un script utilisant le système de pagination de l'API
|
||||
ou tout récupérer d'un coup au risque de mettre une pression importante sur votre serveur.
|
||||
|
||||
Ayant moins de 10 000 entrées, j'ai tout récupéré d'un coup :
|
||||
|
|
@ -201,7 +202,6 @@ cat rooms.json \
|
|||
done
|
||||
```
|
||||
|
||||
|
||||
## Finir par mettre les mains dans le SQL
|
||||
|
||||
```bash
|
||||
|
|
@ -212,7 +212,7 @@ alias mpsql='psql -h 127.0.0.1 -U matrix synapse'
|
|||
Pour avoir une idée de ce "coût", nous avons du passer par SQL (attention les commandes mettent beaucoup de temps à s'exécuter).
|
||||
|
||||
Cette première commande permet d'avoir le nombre ???
|
||||
Vous pouvez adapter la limite pour afficher plus de
|
||||
Vous pouvez adapter la limite pour afficher plus de
|
||||
|
||||
```sql
|
||||
SELECT room_id, count(*) AS count
|
||||
|
|
@ -266,11 +266,14 @@ retention:
|
|||
- interval: 1d
|
||||
```
|
||||
|
||||
|
||||
## VACUUM FULL et Tablespace, un duo de choc
|
||||
|
||||
Un tablespace est un concept dans PostgreSQL qui permet de stocker les données d'une database à un autre emplacement sur le disque. Dans notre cas, on a une configuration avec un petit SSD et un gros HDD. J'ai créé un tablespace sur le HDD pour la base de donnée Synapse, qui avait donc plein d'espace à elle, ce qui m'a permis de lancer un VACUUM FULL.
|
||||
|
||||
## Quand le WAL te met au pied du mur
|
||||
|
||||
PostgreSQL, pour gérer sa réplication, envoie un WAL, Write-Ahead Log. C'est à dire toutes les modifications à faire pour arriver à l'état actuel. Malheureusement il n'y aucun mécanisme de control flow pour gérer ce WAL : autrement dit, la base de donnée ne ralentit pas son travail pour que le WAL reste à une taille constante. On a donc le problème traditionnel des files d'attentes, avec une file qui grandit à une taille infinie. La plupart du temps en réalité ça ne pose pas problème car la base de donnée est moins sollicitée que la vitesse à laquelle elle est capable d'envoyer le WAL. Mais un VACUUM va créer une quantité énorme d'entrée WAL, de l'ordre de la taille de la table qui est nettoyée, et à une vitesse proche de la vitesse théorique du support de stockage, soit plus rapide que le réseau 100Mbit/s que l'on avait dans le cas d'un SSD. Ajouté à ça qu'un des réplicas utilisait un SSD défaillant qui lisait/écrivait à plus que quelques 10Mbit/s, toute tentative de maintenance résultait en un remplissage des SSD avec du WAL…
|
||||
|
||||
## Stolon : initialisation, mise à jour et subtilités
|
||||
|
||||
keeper a besoin de la libc
|
||||
|
|
@ -282,3 +285,5 @@ import/export sql, le trick de pv :P
|
|||
## D'autres outils
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue