Au cours de la semaine dernière, nous avons constaté que trois instances Sidekiq sur différents forums étaient bloquées. Il ne se passait rien de spécial, Sidekiq ne traitait aucun travail et affichait 5 des 5 tâches en cours de traitement.
Une chose intéressante qu’elles avaient toutes en commun était qu’il y avait une tâche critique BotInput parmi les tâches. C’est une tâche assez courante, mais elle se démarque toujours.
Après avoir redémarré Sidekiq, tout fonctionne normalement à nouveau. La mise en file d’attente manuelle d’une tâche avec les mêmes paramètres ne provoque plus de blocage. Il n’y a rien de spécial avec le message spécifique pour lequel elle a été appelée.
Quelqu’un a-t-il une idée de la façon dont nous pourrions suivre ce qui se passe ici ?
J’ai des problèmes avec Sidekiq depuis une mise à niveau du forum il y a un mois. Quelle commande utilisez-vous pour redémarrer Sidekiq ? Juste un sv restart sidekiq ?
Je vois cela depuis quelques jours. Finalement, tous les travaux cessent de s’exécuter. Auparavant, je redémarrais, mais est-il prudent de supprimer la file d’attente critique ? Est-ce une file d’attente Redis ?
Je suis à jour avec la version 3.5.0.beta1-dev.
Juste une supposition, mais parfois, lorsque je discute avec le bot, il cesse de répondre, alors je rafraîchis la page ou j’abandonne. Peut-être que ces cas laissent un travail en suspens ?
Ces travaux sont asynchrones, donc ils ne sauraient même pas que vous avez fait cela.
Il est intéressant d’apprendre que vous rencontrez ce problème également sur Jobs::BotInput. Nous constatons ce problème sur un très petit sous-ensemble de tous nos serveurs (quelques pour cent) et il semble que ce soient les instances qui utilisent le bot narratif de manière assez intensive.
Non, vous perdriez également tous les autres travaux mis en file d’attente.
Le moyen le plus simple et le plus sûr est sv reload unicorn depuis l’intérieur du conteneur.
J’ai examiné les traces de pile et tout semble indiquer un problème avec la ligne suivante :
Je ne suis pas tout à fait sûr pourquoi cette ligne causerait des problèmes, mais c’est une ligne qui n’est pas nécessaire, donc je l’ai supprimée dans
@RGJ Avez-vous par hasard défini Rails.application.config.eager_load sur false pour une raison quelconque ?
Découverte intéressante, merci d’avoir enquêté.
Il est difficile de savoir quand un problème aussi intermittent disparaît. J’ai supprimé cette ligne dans les trois instances qui se bloquaient le plus souvent (l’une d’elles presque quotidiennement). Je reviendrai ici :
lorsqu’une de ces instances se bloquera (nous saurons alors que cela n’a pas suffi)
vendredi si aucune d’elles ne s’est bloquée (nous pourrons alors commencer à supposer que c’était la solution)
Bien que les problèmes se soient produits cette semaine, ils ne se sont pas produits sur les trois instances où nous avons supprimé cette ligne require, donc je pense que nous pouvons supposer sans risque que c’est le coupable . Merci de l’avoir repéré @tgxworld, je ne l’aurais jamais trouvé.
Serait-il possible de rétroporter ce correctif vers la version stable ?
. Merci de l’avoir repéré