Problèmes de performance avec Pleroma
04 novembre 2024 Rédigé par Linuxine
J'ai essayé plusieurs titres pour ce post : "Le jour où Pleroma est devenu fou", "Le jour où j'ai failli supprimer mon instance Pleroma", "Pleroma a failli tuer mon serveur"... finalement on va faire moins "putaclic" et rester sobre, mais je n'en pense pas moins !
Car oui, en ce long week-end de pont du 1er novembre, j'ai failli fermer mon instance Pleroma, car elle prenait irrémédiablement toutes les ressources sur mon serveur et générait un nombre d'I/O qui menaçaient la survie à court terme de mon disque.
Commençons par le diagnostic: en fin de semaine dernière, mon serveur était inhabituellement lent. En cause ? La charge était à 8 en permanence (sur 8 CPU, ça se ressent), et surtout les I/O étaient très élevés. Les coupables ? Plein de process Postgres à 100% de CPU, lancés par Pleroma, qui concernaient tous une mystérieuse une table "oban_jobs" qui se faisait mettre à jour en permanence. Si je coupais mon instance, la charge retombait instantanément proche de zéro, et plus aucun I/O.
Étant habituée à ce que la base de données Pleroma grossisse avec le temps (on parle d'un réseau social fédéré, donc avec beaucoup d'interactions à gérer), au début je ne me suis pas inquiétée, je me suis dit qu'il était temps de pruner un peu et de faire du ménage dans la base. Mais une fois les "prune" et autres "vaccum" réalisés, si la taille de la base avait diminué de moitié, passant de 60GB tout de même à 30, l'effet n'était pas aussi spectaculaire qu'escompté. Certes, la charge de mon serveur n'était plus qu'à 4 et non 8, mais les I/O étaient toujours en folie, et toujours autant de requêtes d'update sur la table "oban_jobs". 300 requêtes par seconde, pour une instance avec un unique utilisateur, ça me paraissait beaucoup...
Arrivée à ce stade de l'enquête, j'ai tenté beaucoup de choses, hélas sans succès:
- activer les requêtes préparées, comme indiqué dans la page de documentation Pleroma officielle Optimizing PostgreSQL performance ;
- changer la configuration de Postgres pour utiliser moins de workers, mais augmenter la taille des buffers en RAM et autres paramètres de ce type ;
- j'ai même installé pgbouncer pour tenter de mieux gérer les files de requêtes.
Toutes ces actions n'ont eu aucun effet notable. A ce moment là, j'en étais à envisager de fermer mon instance et repasser sous Framapiaf. Je me disais que le passage de Pleroma à oban pour gérer ses jobs avait du complètement casser quelque chose et que je ne pouvais pas y faire grand chose.
Évidemment, j'avais fait des recherches sur mon souci dans tous les sens, interrogé les gens sous Mastodon, mais personne ne semblait avoir un souci de consommation de ressource aussi énorme que moi. Avant de jeter l'éponge, je me dit, foutue pour foutue, essayons de bidouiller la base de donnée. Allons voir cette fameuse table "oban_jobs", peut-être y a- t-il un index manquant ou quelque chose que je pourrais optimiser dessus ? Je commence par compter le nombre de lignes de la taille: 75 millions. Pour une table de jobs, c'est trop, beaucoup trop, pas étonnant que la charge soit élevée. Après un dump de la db, n'écoutant que mon courage, je truncate carrément la table, à la guerre comme à la guerre. Je pensais qu'au pire j'allais tout péter et qu'au mieux ça aiderait. Et bien non seulement ça a aidé, mais ça a résolu le souci... La charge est instantanément devenue inférieure à 1, et les I/O sont devenus inexistants. Bref, mon serveur était sauvé !
Maintenant, la question, c'est: pourquoi ? Cette table de jobs, j'ai vérifié depuis, est sensée se vider régulièrement une fois les jobs accomplis. Pourquoi ne s'est-elle pas vidée ? Est-ce un bug ? Ou bien est-ce lié à la campagne de spam que j'ai reçue récemment ? J'ai reçu de nombreux pouets non sollicités d'un "hacker" japonais qui me taguait, ainsi que de nombreuses autres personnes. J'avais masqué les premiers, mais je n'avais bloqué ni les utilisateurs ni les instances. Est-ce que cela aurait généré des interactions non désirées entre mon instance et trop de serveurs, et donc trop de jobs d'un coup ?
Depuis, je monitore la charge et la taille de cette table et tout semble rentré dans l'ordre. Mais si vous avez des pistes sur le pourquoi du comment, je suis preneuse ! Vous pouvez me les donner ici... ou sous Mastodon, puisque, bonne nouvelle, je ne pars pas ! :D