fcoh-aot
commented
2 weeks ago 20/09 : la bascule 100% ClamAV a fait augmenter la charge de travail des workers FT, les scans AV prennent beaucoup de temps
24/09 : MEP le soir pour ajouter 4 workers supplémentaires. Retour à la normale dans la soirée (traitement d'un scan <1min contre 50min auparavant pour un simple pli, voire >3h pour d'autres)
25/09 : Glimps a désactivé GMalware. MEP pour supprimer les 4 workers supplémentaires, rebasculer 2 workers sur Paasteur (et donc 2 sur ClamAV)
26/09 : de nouveau quelques lenteurs sur les scans AV mais pas aussi importantes qu'entre le 20 et 24/09 (12min pour un pli). MEP le soir-même pour modification de configuration pour permettre à plus de tâches de s'exécuter en parallèle
27/09 : retour à la normale sur les délais de scan AV. Mais le healthcheck montre quelques soucis ponctuels de lenteurs (erreurs 502/503). Au niveau des APIs, le MCE indique avoir des 502/504. On voit que le service "upload" consomme énormément de ressources sur les workers, un restart permet un retour à la normale
30/09 : nouvelles erreurs 502/504 sur APIs remontées par Cyril => restart des upload ne permet pas de tenir assez longtemps. => Modif conf Xmx des upload n'apporte rien non plus => dernière correction : fermeture des fichiers temporaires associés aux chunks => MEP du back
01/10 : pas de lenteurs détectées côté utilisateur, Healthcheck OK. Mais 12 erreurs 502/504 au niveau des APIs. Certains workers sont quand même bien occupés, une piste serait de réduire le nombre de tâches parallèles à faire traiter par les workers Glimps (4->3)
16/10 : plus de lenteurs observées, la volumétrie semble malgré tout plus faible que du 20 au 25/09 globalement où on était monté jusqu'à 1.1TO de données envoyées, contre entre 500 et 700Go désormais. Pas de retours utilisateur manifestant des cas de lenteur, même lorsqu'on bascule automatiquement en 100% ClamAV.
Lenteurs sur les traitements de scan AV puis erreurs 502/504 sur France transfert