J’héberge tous mes fichiers téléchargés sur un stockage NAS (glusterfs).
Récemment, j’ai constaté un trafic réseau énorme et constant sur le NAS. J’ai découvert que cela était dû à Discourse qui demandait des images optimisées. Existe-t-il une tâche qui recherche constamment ces images ? Pourquoi ? Et comment puis-je la désactiver ?
au fait, la désactivation du nettoyage des paramètres du site de téléchargement est désactivée sur mon forum.
Possiblement le remplissage @david ajouté pour la recherche de la couleur d’image principale.
Il finira par se terminer et reviendra à un état stable.
Nous devons parcourir toutes les images pour le remplissage, vous pourrez peut-être contourner le problème en forçant la couleur de toutes les images à blanc ou autre chose.
D’après ce que je vois,
Il traite 25 images par 15 minutes. oui ? cela devrait être très négligeable. Je vois des milliers de fichiers être recherchés chaque minute.
Et en regardant également la bande passante d’il y a 6 mois, je vois le même comportement. Je pense donc que cela devrait être autre chose.
Cependant, je suis à peu près sûr que c’est fait par un job discourse ou quelque chose de similaire, car lorsque j’arrête l’application discourse, la bande passante disparaît. Cependant, lorsque j’arrête juste l’application nginx de discourse, la bande passante reste.
Regardez dans /sidekiq, cela devrait vous indiquer quels travaux sont en cours, assurez-vous de cliquer sur tous les onglets.
Aucun travail n’est en cours. 
. Y a-t-il d’autres travaux qui ne seraient pas répertoriés ici ?
Ou peut-être y a-t-il quelque chose dans le conteneur qui tente d’indexer des fichiers ?
Toute notre logique d’arrière-plan s’exécute sur des tâches Sidekiq. Si aucune tâche ne s’exécute et que vous avez toujours une activité disque élevée, cela pourrait-il être des utilisateurs visitant votre site Web et des images servies par nginx ?
Avez-vous un CDN de mise en cache devant vos ressources statiques ?
J’ai déjà testé cela.
Donc ce n’est pas parce que des utilisateurs visitent le site web. Si c’était le cas, quand j’aurais arrêté nginx, le trafic aurait dû disparaître.
Vous devrez utiliser les outils d’inspection Linux pour voir exactement quels PID et appels système sont effectués alors.
@Falco @sam Je pense avoir trouvé la cause première.
J’ai d’abord redémarré l’application Discourse pour que le trafic constant disparaisse. Ensuite, je suis allé dans le panneau d’administration et dans la section des rapports en masse. Cela fait longtemps que les rapports ne s’affichent pas correctement ici :
Immédiatement après que les rapports aient expiré, j’ai vu un pic de bande passante réseau. Et j’ai vu cette erreur dans les journaux d’erreurs :
'hijack admin/reports bulk ' est toujours en cours d'exécution après 90 secondes sur la base de données par défaut, ce processus peut nécessiter un redémarrage !
Qu’est-ce qui ne va pas ici ?
La base de données se trouve-t-elle dans le même stockage NAS ?
Non, la base de données se trouve sur le disque SSD physique.
Seul le dossier de téléchargement est sur le NAS.
Il n’y a donc aucune corrélation entre ceux-ci. Retournons à
En fait, je pense qu’il y a peut-être une corrélation. Dans mon environnement de test ici, il calcule l’espace utilisé.
Je pense que le calcul de l’espace utilisé sur un dossier NAS contenant beaucoup de fichiers prendrait beaucoup de temps et serait la cause principale d’une bande passante élevée.
Ai-je raison ?
Est-ce que l’exécution de
df -Pk
df -P
du -s
prend beaucoup de temps sur le partage réseau ?
ces deux-là ont été instantanés
df -Pk
df -P
Cependant, du -s a eu un comportement similaire à celui que j’ai signalé ci-dessus.
Et il tournait depuis environ 5 minutes et ne s’est pas terminé, j’ai dû l’arrêter manuellement.
Je vois. Le résultat de ce rapport est mis en cache, mais je suppose qu’il ne se termine jamais et ne peut pas être mis en cache car votre partage réseau est trop lent.
Alors, y a-t-il quelque chose que nous puissions faire pour éviter cela ? Par exemple, le traiter comme des téléchargements s3 où nous ne calculons pas la taille du disque.
