Surveiller Synapse S3 Storage Provider

quentin commented

2021-09-17 16:56:44 +00:00

Owner

Le fonctionnement de Synapse avec les médias est vraiment inintuitif.
Il possède:

un media_provider nécessairement sur le stockage de fichier, qui est le point d'entrée principal pour les médias
une extension storage_provider sur laquelle on a connecté S3.

Synapse va d'abord regarder si le média est présent sur le media_provider et ensuite sur le storage_provider, tout le temps.

On peut dire à synapse d'envoyer de manière synchrone les médias sur le storage provider ou de manière asynchrone, avec un script à exécuter par un cron.

J'ai configuré de manière synchrone.

Par contre les médias sont toujours stockés localement, ça agit comme un cache à la taille infinie.

Deux problèmes donc:

Il faut vider le cache à la main avec un cron
J'ai remarqué, du moins quand le fs local était GlusterFS, que beaucoup de médias manquaient à l'appel grâce au script d'envoi asynchrone.

Le script donne :

Uploading  255  files
Uploaded 166 files out of 255
Uploaded 44.5M
Deleted 255 files
Deleted 73.9M

Alors que si l'envoi synchrone fonctionnait correctement, le script d'envoi asynchrone devrait dire :

...
Uploaded 0 files out of 255
Uploaded 0M
...

Il va falloir vérifier dans les prochains jours si le point 2 est bien du à GlusterFS et donc si il est résolu. Sinon, ça peut être intéressant de voir à debugger ça.

https://github.com/matrix-org/synapse-s3-storage-provider

Le fonctionnement de Synapse avec les médias est vraiment inintuitif. Il possède: - un `media_provider` nécessairement sur le stockage de fichier, qui est le point d'entrée principal pour les médias - une extension `storage_provider` sur laquelle on a connecté S3. Synapse va d'abord regarder si le média est présent sur le `media_provider` et ensuite sur le `storage_provider`, tout le temps. On peut dire à synapse d'envoyer de manière synchrone les médias sur le storage provider ou de manière asynchrone, avec un script à exécuter par un cron. J'ai configuré de manière synchrone. Par contre les médias sont toujours stockés localement, ça agit comme un cache à la taille infinie. Deux problèmes donc: 1. Il faut vider le cache à la main avec un cron 2. J'ai remarqué, du moins quand le fs local était GlusterFS, que beaucoup de médias manquaient à l'appel grâce au script d'envoi asynchrone. Le script donne : ``` Uploading 255 files Uploaded 166 files out of 255 Uploaded 44.5M Deleted 255 files Deleted 73.9M ``` Alors que si l'envoi synchrone fonctionnait correctement, le script d'envoi asynchrone devrait dire : ``` ... Uploaded 0 files out of 255 Uploaded 0M ... ``` Il va falloir vérifier dans les prochains jours si le point 2 est bien du à GlusterFS et donc si il est résolu. Sinon, ça peut être intéressant de voir à debugger ça. https://github.com/matrix-org/synapse-s3-storage-provider

quentin added this to the Maintenance Matrix Synapse milestone 2021-09-17 16:56:44 +00:00

quentin added the

maintenance

label 2021-09-17 16:56:44 +00:00

quentin self-assigned this 2021-09-17 16:56:44 +00:00

quentin commented

2021-09-20 07:57:01 +00:00

Author

Owner

Je me suis trompé dans l'écriture de mon service et mon script ne tournait pas sur la bonne machine alors qu'il a besoin d'accéder au système de fichier du daemon synapse. C'est maintenant corrigé dans 88a7c04cee.

Ça fonctionne comme prévu pour l'instant:

Syncing files that haven't been accessed since: 2021-09-20 07:52:01.825799
Synced 1283 new rows
Checking on  1342  undeleted files
Updated 1145 as deleted
Uploading  197  files
Uploaded 0 files out of 197
Uploaded 0B
Deleted 197 files
Deleted 59.5M

Uploaded 0 files out of 197 veut dire qu'aucun fichier ne manque à l'appel sur S3
Deleted 197 files veut dire qu'on supprime bien des fichiers du cache local

Je laisse ce ticket ouvert quelques jours de plus au cas où...

Je me suis trompé dans l'écriture de mon service et mon script ne tournait pas sur la bonne machine alors qu'il a besoin d'accéder au système de fichier du daemon synapse. C'est maintenant corrigé dans 88a7c04cee28c0cfc631f9398b66d6ee951c4586. Ça fonctionne comme prévu pour l'instant: ``` Syncing files that haven't been accessed since: 2021-09-20 07:52:01.825799 Synced 1283 new rows Checking on 1342 undeleted files Updated 1145 as deleted Uploading 197 files Uploaded 0 files out of 197 Uploaded 0B Deleted 197 files Deleted 59.5M ``` 1. `Uploaded 0 files out of 197` veut dire qu'aucun fichier ne manque à l'appel sur S3 2. `Deleted 197 files` veut dire qu'on supprime bien des fichiers du cache local Je laisse ce ticket ouvert quelques jours de plus au cas où...

quentin commented

2021-09-23 05:42:00 +00:00

Author

Owner

Moui c'est pas une réussite, le dossier media reste de taille importante, il fait 146Mo actuellement.

Je ferme mais j'ouvre une issue pour migrer vers matrix-media-repo.

Moui c'est pas une réussite, le dossier media reste de taille importante, il fait 146Mo actuellement. Je ferme mais j'ouvre une issue pour migrer vers matrix-media-repo.

quentin closed this issue

2021-09-23 05:42:01 +00:00

Surveiller Synapse S3 Storage Provider #48