¿Sidekiq se cuelga (en el trabajo BotInput?)

Soporte
1

En la última semana hemos visto tres instancias de Sidekiq en diferentes foros atascadas. No estaba pasando nada especial, simplemente Sidekiq no estaba procesando ningún trabajo y mostraba 5 de 5 trabajos en proceso.

Algo interesante que tenían en común era que había un trabajo crítico de BotInput entre los trabajos. Ahora, este es un trabajo bastante común, pero aún así destaca.

Después de reiniciar Sidekiq, todo vuelve a funcionar con normalidad. Poner en cola manualmente un trabajo con los mismos parámetros no hace que se cuelgue de nuevo. No hay nada especial en la publicación específica para la que se llamó.

¿Alguien tiene alguna idea de cómo podríamos rastrear qué está pasando aquí?

1 me gusta
2

También hemos tenido bloqueos como este, y nuestro host no puede averiguar qué los está causando.

3

¿Tienes una captura de pantalla de lo que ves en el panel?

Si puedes, intenta enviar al proceso de Sidekiq la señal TTIN y proporciona el backtrace aquí.

1 me gusta
4

Lo siento, tardó un tiempo antes de que esto volviera a suceder.

sidekiq-20250220
sidekiq-202502201371×1171 190 KB

sidekiq-clean.txt (35.8 KB)

Resumen de los registros

[default] Thread TID-1ow77
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/cli.rb:199:in `backtrace'
--
[default] Thread TID-1o1jr
[default] /var/www/discourse/lib/demon/base.rb:234:in `sleep'
--
[default] Thread TID-1o1j7
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/connection/ruby.rb:57:in `wait_readable'
--
[default] Thread TID-1o1j3
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/timer_thread.rb:130:in `sleep'
--
[default] Thread TID-1o1ij AR Pool Reaper
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/connection_pool/reaper.rb:49:in `sleep'
--
[default] Thread TID-1o1hj
[default] --
[default] Thread TID-1o1gz AR Pool Reaper
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/connection_pool/reaper.rb:49:in `sleep'
--
[default] Thread TID-1o1gv
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:18:in `sleep'
--
[default] Thread TID-1o1gb
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:32:in `sleep'
--
[default] Thread TID-1otmb
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1otkn
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1otjz
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1otif
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1othr
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1o1fb
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler.rb:80:in `sleep'
--
[default] Thread TID-1o1er
[default] /var/www/discourse/lib/mini_scheduler_long_running_job_logger.rb:87:in `sleep'
--
[default] Thread TID-1o1en heartbeat
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/launcher.rb:76:in `sleep'
--
[default] Thread TID-1o1e3 scheduler
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/connection_pool-2.5.0/lib/connection_pool/timed_stack.rb:79:in `sleep'
--
[default] Thread TID-1ot4n processor
[default] /var/www/discourse/app/models/email_log.rb:58:in `unique_email_per_post'
--
[default] Thread TID-1ot67 processor
[default] /var/www/discourse/app/models/email_log.rb:58:in `unique_email_per_post'
--
[default] Thread TID-1ot8j processor
[default] /var/www/discourse/app/models/email_log.rb:58:in `unique_email_per_post'
--
[default] Thread TID-1ot5n processor
[default] /usr/local/lib/ruby/3.3.0/bundled_gems.rb:74:in `require'
--
[default] Thread TID-1ot6b processor
[default] /var/www/discourse/lib/distributed_mutex.rb:5:in `<main>'
--
[default] Thread TID-1o0kn final-destination_resolver_thread
[default] --
[default] Thread TID-1o0k3 Timeout stdlib thread
[default] --
5

@tgxworld ¿tuviste oportunidad de ver el backtrace?

7

He estado teniendo problemas con Sidekiq desde una actualización del foro hace un mes. ¿Qué comando usas para reiniciar Sidekiq? ¿Solo un sv restart sidekiq?

8

Lo siento, aún no he tenido la oportunidad de revisarlo. Intentaré hacerlo esta semana.

1 me gusta
9

He estado viendo esto en los últimos días. Eventualmente, todos los trabajos dejan de ejecutarse. Anteriormente reinicié, pero ¿es seguro eliminar la cola crítica? ¿Es una cola de redis?

Estoy actualizado en 3.5.0.beta1-dev.

Solo una suposición, pero a veces, cuando estoy chateando con el bot, deja de responder, así que actualizo la página o me rindo. ¿Quizás esos casos dejan un trabajo colgado?

image
image1590×952 187 KB

image
image1526×1498 508 KB

1 me gusta
10

Estos trabajos son asíncronos, por lo que ni siquiera sabrían que hiciste eso.

Es interesante saber que también estás experimentando esto en Jobs::BotInput. Estamos viendo este problema en un pequeño subconjunto de todos nuestros servidores (unos pocos por ciento) y parece que son las instancias que usan el bot narrativo bastante intensamente.

No, perderías todos los demás trabajos en cola también.

La forma más fácil y segura es sv reload unicorn desde dentro del contenedor.

1 me gusta
11

Ese no es el caso de nuestro foro. La IA solo es visible para el personal y he confirmado que ningún miembro del personal la está utilizando.

He deshabilitado la IA por ahora.

12

BotInput es una tarea del Discourse Narrative Bot (también conocido como Discobot), no del bot de IA.

13

Ah. He estado usando la API intensamente, como el nombre de usuario discobot.

14

Heché un vistazo a los rastreos de pila y todo apunta a algún problema con la siguiente línea:

No estoy muy seguro de por qué esa línea causaría problemas, pero es una línea que no es necesaria, así que la he eliminado en

@RGJ ¿Tienes por casualidad Rails.application.config.eager_load configurado en deshabilitado por alguna razón? :thinking:

2 Me gusta
16

Hallazgo interesante, gracias por investigarlo.
Es difícil saber cuándo desaparece un problema intermitente. He eliminado esa línea en las tres instancias que se colgaron con más frecuencia (una de ellas casi a diario). Volveré a consultar aquí:

  • cuando una de esas instancias se cuelgue (entonces sabremos que esto no funcionó)
  • el viernes si ninguna de ellas se colgó (entonces podremos empezar a asumir que fue la solución)

No, no toqué eso.

Pero alguien lo hizo…

Rails.autoloaders.main.do_not_eager_load(config.root.join("lib"))

en Blaming discourse/config/application.rb at main · discourse/discourse · GitHub

3 Me gusta
17

@loic ¿Recuerdas por qué no cargamos previamente el directorio lib incluso en producción?

1 me gusta
18

Si bien los problemas han estado ocurriendo esta semana, no han estado sucediendo en las tres instancias donde eliminamos esa línea require, así que creo que podemos asumir con seguridad que este es el culpable :tada: . Gracias por darte cuenta, @tgxworld , yo nunca lo habría encontrado.

¿Sería posible que incluyeras ese arreglo en la versión estable?

1 me gusta
19

Está relacionado con lo que se explica aquí (cuando actualizamos a Rails 7.1): Upgrading Ruby on Rails — Ruby on Rails Guides

No recuerdo el problema exacto, pero en realidad mantuvimos el comportamiento anterior, teniendo que requerir cosas de lib.